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:
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)]
@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?