Who broke SparseSet? (JUCE 5.3.1)

This might have happened in 5.3.0; noticed at 5.3.1

My client just found a major bug in the runtime of the application after I upgraded to JUCE 5.3.1 in my last release. I have just tracked down the issue - the behaviour of SparseSet has changed. The function causing the issue is ::removeRange. In my use case the SparseSet is filling up with empty ranges (ie. start:312, end:312) as the result of removeRange operations.

An illustration of the bug:
SparseSet lTest;
lTest.addRange(Range(0, 10)); // A
lTest.removeRange(Range(0, 2)); // B
lTest.removeRange(Range(5, 5)); // C

Correct lTest -
@A: [(0,10)] @B: [(2,10)] @C: [(2,10)]
actual lTest
@A: [(0,10)] @B [(0,0), (2,10)] @C[(0,0), (2,10)]

…which really screws up my threadpool completion condition based on a sparse set of work to be done being emptied…

unit tests people!

And perhaps - if it isn’t broken, do not fix it?

1 Like

I guess the bug comes from this commit: https://github.com/WeAreROLI/JUCE/commit/809651694e33eb97b52944c5f7a2136713980eb3. You could revert it as a hot fix.

I’ve left a comment on what might be the bug: https://github.com/WeAreROLI/JUCE/commit/809651694e33eb97b52944c5f7a2136713980eb3#r28730800

Pinging @jules, in case he doesn’t see the comment on GitHub.

Thanks for the report and sorry for the regression. We will fix this shortly.

The fix + unit tests are now on develop, added in commit bac6996

1 Like

Thanks for the rapid confirmation and response.