Open RareBreeds opened 2 years ago
The crash on start usually is a one-shot here on my M1 Mini. If I open Rack after crash and tell it to go open patch anyway it will open. Has been reproduced by the folks at VCV and under investigation. However the other issues I have not seen here…
I've been running address sanitizer builds of open source plugins and this plugin had a few crashes in different layers of the code.
The crashes are around how lookup table accesses are implemented, say the range is [0.0, 1.0] and we're try to look up a value for exactly 1.0, the code is accessing one off the end of the array.
I don't know if these out of bounds accesses actually cause crashes, I haven't reproduced a crash in a non ASAN build, but these crashes do look like they could be the cause of bugs #64 and #80.
Configuration
OS: macOS 12.5 Beta HW: M1 Max MacBook Pro Rack: 5551617afff182925940908eaf73a7d7361303cc Plugin: a1cd335ec6ac44e8be55891854015bf0763f8552 Arch: Both apple silicon native builds and x86 fail
Steps
make -j10 EXTRA_FLAGS=-fsanitize=address EXTRA_LDFLAGS=-fsanitize=address
Results
ASAN reports out of bounds accesses. I've detailed the 3 issues I ran into below. After applying workarounds I was unable to cause any more ASAN crashes with this patch, although clearly there are other issues in the source as these are just point fixes in some of the interpolation functions and there are others written in a similar way.
The workarounds I applied are likely not the real fixes, but they got me to the next issue.
1. Plaits - activeEngines
ASAN Crash Log
Debugger
Workaround
2. stmlib - Interpolate
ASAN Crash Log
Debugger
Workaround
This just hacks the one interpolate function that failed, there's other functions that I imagine suffer from the same issue.
3. Keyframer - easing_curve
ASAN Crash Log
Debugger
Workaround