You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2023. It is now read-only.
Hey there. Thanks for your great API.
We're in the middle of integrating REAPER into our software, and it seems awesome. However, we noticed a lot of seemingly random crashes, related to either allocation or deallocation, when running a lot of iterations of ResampleAndReturnResults. Looking through it, I stumbled across
In the for loop, if i == 0,
frame = 37976 / 882 = 43,05 (round up ->) = 44
That's an out-of-bounds for the f0 vector that's only allocated 43, trying to access 44 (counting from zero). I suspect this to be the reason for the "random" crashes later on. What would the expected behavior be? Should it rather just be:
I have found this same memory corruption. A few notes from what I found:
Our team believes RoundUp() to be misleadingly named, it is doing traditional rounding where [X + .5, X + 1.5) will round to X. It's more of just...Round.
The point still remains the same. I can end up with a situation where, for example, the float being rounded for size is (97.499999999) and the float being rounded for index is (96.5), so the vector ends up overrunning by one.
I duplicated this from the command line. I unfortunately can't share the wav, but this command:
build/reaper -i <some_unlucky_wav_file> -f freq.f0 -p pitchmark.pm -a -e 0.01
will cause a memory corruption (I hunted down the source using ASAN and it identified this invalid write as described).
It doesn't happen with every wav file, but once you find one where it happens it is consistent.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey there. Thanks for your great API.
We're in the middle of integrating REAPER into our software, and it seems awesome. However, we noticed a lot of seemingly random crashes, related to either allocation or deallocation, when running a lot of iterations of ResampleAndReturnResults. Looking through it, I stumbled across
Let's just do some math here.
Let's assume:
output[0].resid_index = 37976
sampleRate = 44100
resample_interval = 0.02
Yields:
lastTime = 0,8611
n_frames = 44
In the for loop, if i == 0,
frame = 37976 / 882 = 43,05 (round up ->) = 44
That's an out-of-bounds for the f0 vector that's only allocated 43, trying to access 44 (counting from zero). I suspect this to be the reason for the "random" crashes later on. What would the expected behavior be? Should it rather just be:
int32_t frame = RoundUp(output_[i].resid_index / (sample_rate_ * resample_interval)) -1;
?
All the best,
Sebastian
The text was updated successfully, but these errors were encountered: