Closed psobot closed 2 years ago
Ouch! Thank you, I will look into it.
I've pushed a fix, and added to my local test set a program to exercise this situation with an exhaustive set of option combinations. Please test!
The way memory is managed throughout is decidedly antique and it's on my slate to revise it, but an immediate fix is far more important. I'll make another release with this fix in the coming days.
Thanks again for the very clear report and test case.
Thanks @cannam! That was incredibly fast - I can confirm that this no longer crashes, either in the provided test case or in my application. Much appreciated!
Hello again! I think I've run across a very rare edge case with Rubber Band. I seem to be able to consistently make Rubber Band write past the end of an internal buffer and cause a crash when the following conditions are true:
process
(i.e.: passing in more thangetSamplesRequired()
)OptionProcessRealTime
,OptionChannelsTogether
andPitchHighSpeed
are all passedIn this case, Address Sanitizer reports a heap buffer overflow past the end of the
ms
buffer:The following test harness seems to reliably reproduce the above crash (only tested on my machine so far, macOS x86):
Please let me know if you need any more details. (I think it should be possible to work around this crash by only passing at most
getSamplesRequired()
samples per call toprocess
, but I haven't experimented too much further with that yet.)