~breakfastquay/rubberband#18: 
Assertion in MovingMedian::drop

I have an assertion crash showing up in the logs at MovingMedian.h:101, in drop:

assert(*index == value);

This is happening during a non-realtime tempo change (constant pitch) operation, from within 'study' (on iOS 14.6). Full stack trace:

__pthread_kill + 8
pthread_kill + 272
abort + 104 (abort.c:110)
__assert_rtn + 292 (assert.c:96)
RubberBand::MovingMedian<double>::drop(double) (.cold.1) + 40 (MovingMedian.h:101)
RubberBand::MovingMedian<double>::drop(double) + 136 (MovingMedian.h:101)
RubberBand::MovingMedian<double>::push(double) + 36 (MovingMedian.h:68)
RubberBand::CompoundAudioCurve::processFiltering(double, double) + 68 (CompoundAudioCurve.cpp:131)
RubberBand::CompoundAudioCurve::processFloat(float const*, int) + 168 (CompoundAudioCurve.cpp:97)
RubberBand::RubberBandStretcher::Impl::study(float const* const*, unsigned long, bool) + 1300 (StretcherImpl.cpp:1034)

I don't yet know how to reproduce the crash; will update the ticket if more info becomes available.

Status
REPORTED
Submitter
~michaeltyson
Assigned to
No-one
Submitted
2 months ago
Updated
2 months ago
Labels
No labels applied.

~michaeltyson 2 months ago*

I just found another crash in the same spot - this time, RB was used realtime to perform a pitch change (tempo constant). Here's the stack trace:

__pthread_kill + 8
pthread_kill + 272
abort + 104
err + 0
RubberBand::MovingMedian<double>::drop(double) (.cold.1) + 40 (MovingMedian.h:101)
RubberBand::MovingMedian<double>::drop(double) + 136 (MovingMedian.h:101)
RubberBand::MovingMedian<double>::push(double) + 36 (MovingMedian.h:68)
RubberBand::CompoundAudioCurve::processFiltering(double, double) + 68 (CompoundAudioCurve.cpp:131)
RubberBand::RubberBandStretcher::Impl::calculateIncrements(unsigned long&, unsigned long&, bool&) + 388 (StretcherProcess.cpp:611)
RubberBand::RubberBandStretcher::Impl::processOneChunk() + 272 (StretcherProcess.cpp:368)
RubberBand::RubberBandStretcher::Impl::process(float const* const*, unsigned long, bool) + 912 (StretcherImpl.cpp:1331)

This is using the latest version of the library from the repository.

~cannam 2 months ago

Thanks - this is concerning. I'll see if I can work out what might be going on.

If there is any way you can extract the value of value and the contents of the array at m_sorted (of length m_size, which will be 19) at this point, that might be enlightening.

~cannam 2 months ago*

I've reviewed the code and run some quite intensive tests, and I am fairly sure that this can only happen if a NaN has found its way into the moving-median filter.

There is a test for NaN in MovingMedian::push, but it won't work if -ffast-math is used to compile the code. In that situation, any NaN found at the input will go straight into the filter and cause this assertion to fail on retrieval shortly afterward.

So I'd say first question is whether you are in fact building with -ffast-math. If you are, try rebuilding without, and see if the problem goes away or is replaced by stderr output from the line in MovingMedian::push that checks for NaN values. (It should be fine to build Rubber Band with -ffast-math, it's just that some safety checks like this are lost.)

This MovingMedian filter contains spectral summary data from the input, which has been through windowing and a forward FFT but not much else - no phase manipulation and, certainly in the case of the study() call, it has not encountered the complexity of a resampler yet. If there are NaNs in the signal at this point, I think the most likely - and hopefully easiest to test - explanation would be that a NaN value has actually been passed to Rubber Band as input. Can you readily check this?

~michaeltyson 2 months ago*

Thank you very much for all that! I am indeed using -ffast-math, so I'll turn it off and see what happens. I'd be surprised if there are any NaN's in the input (with the offline render it's coming straight from an audio file reader, with no filtering/etc), but you never know. Will report back.

Alas, I can't retrieve any values (I haven't been able to repro the crash myself, so all I'm getting are crash logs with the stack trace).