Are you able to build the plugin yourself?
If so you need to use GDB with a debug build of the plugin otherwise logs will show nothing of use.
Here’s my crash log from using a debug build on Win10 Rack v2.1.0. [Adding Peaks from the module browser.]
This is problem in the firmware. Analysis and fix is here: Peaks clone ? - #59 by Steve_Russell
Thread 31 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 11776.0xd60]
0x00007ffd46336ba4 in peaks::MultistageEnvelope::Process (this=0x1eba645d6c0, gate_flags=0x1eba645f17d "", out=0x1eba645e134, size=5116086978860809725) at eurorack/peaks/modulations/multistage_envelope.cc:81
81 uint16_t t = Interpolate824(
(gdb) bt
#0 0x00007ffd46336ba4 in peaks::MultistageEnvelope::Process (this=0x1eba645d6c0, gate_flags=0x1eba645f17d "", out=0x1eba645e134, size=5116086978860809725)
at eurorack/peaks/modulations/multistage_envelope.cc:81
#1 0x00007ffd463526fc in peaks::Processors::Process (size=4, output=0x1eba645e130, gate_flags=0x1eba645f17a "", this=0x1eba645d680)
at ./eurorack/peaks/processors.h:124
#2 Peaks::process (size=<optimized out>, block=<optimized out>, this=<optimized out>) at src/Peaks.cpp:563
#3 Peaks::process (this=0x1eba645d4d0, args=...) at src/Peaks.cpp:485
#4 0x00007ffd480d5a1a in libRack!_ZN4rack6engine6Module9doProcessERKNS1_11ProcessArgsE () from /c/Program Files/VCV/Rack2 Pro/libRack.dll
#5 0x00007ffd480d0a92 in libRack!_ZN4rack6engine6Engine9stepBlockEi () from /c/Program Files/VCV/Rack2 Pro/libRack.dll
#6 0x00007ffd480d1296 in libRack!_ZN4rack6engine6Engine9stepBlockEi () from /c/Program Files/VCV/Rack2 Pro/libRack.dll
#7 0x00007ffd4e761371 in ?? () from /c/Program Files/VCV/Rack2 Pro/libstdc++-6.dll
#8 0x00007ffd66624d53 in ?? () from /c/Program Files/VCV/Rack2 Pro/libwinpthread-1.dll
#9 0x00007ffd7d5caf5a in msvcrt!_beginthreadex () from /c/WINDOWS/System32/msvcrt.dll
#10 0x00007ffd7d5cb02c in msvcrt!_endthreadex () from /c/WINDOWS/System32/msvcrt.dll
#11 0x00007ffd7c217034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#12 0x00007ffd7dca2651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#13 0x0000000000000000 in ?? ()
1 Like
don’t know what that size is, but it sure it a big number.
Strange as I’ve built the plugin using a local clone of Ewan’s WIP fork and it’s been fine. Hadn’t done any testing since yesterday, and now (having caught up with this thread) Peaks crashes.
So I think I might have fixed the issue. I could repro the crash on Win11 VM, now working for me.
The original code had:
memset(&processors[0], 0, sizeof(processors[0]));
memset(&processors[1], 0, sizeof(processors[1]));
in the constructor. I was getting a warning about this, so I switched to peaks::Processors processors[2] = {}; where it is declared. This worked on Mac, but clearly not on Windows. I’ve not used memset with complex types at least for a while, and I don’t know the internals of the original MI code - clearly there are some uninitalised variables there. Also I think the 2.1.0 vs 2.0.6 thing is a red herring, I’ve just tested the version from github (built against 2.1.0 SDK) in Rack 2.0.6.
Builds have been updated, let me know if this works. 
1 Like
No crashes but no Peaks either … 
Oh dear. I’d make sure you haven’t automatically downgraded to the library version (delete AudibleInstrucments in plugins folder, re-download from github, etc). Anyone else have this issue?
This may warrant its own topic, but @Squinky got a lot of uninitialized variables warnings when running address sanitizer, valgrind, etc. on my crashing patch. I have gone through Meander and tried to make sure all variables are iniitialized, but it can be tedious. I have not submitted these Meander fixes to the library yet. But, he found lots of these warning for a number of highly used plugins. He can probably say more on this if he is interested.
1 Like
Nice I’m always interested in those sorts of topics. In this case I suspect the issue is in the actual upstream mutable code (rather than the VCV plugin), which makes it harder to fix (I don’t think Emilie is necessary accepting PRs for those sorts of things).
here, on Win11, it works now 
1 Like
Ah, I missed that the uninitialized variables are in the upstream code.
yep - this is where went wrong just automatically clicked update; working now 
Been there done that, occasionally intentionally 
I don’t have GDB set up yet, I’ll look into it today. The first log I posted was the built version with -d.
I’ll build this and test it when I get to it today!
Yeah, I get mixed up with the rules to initialize c arrays. the actual original memset looks ok, but ?? I did try a few versions of {} using the microsoft compiler for windows. Seems it doesn’t do what we want it to?
static void testx() {
int x[5] = { 123 };
int y[5]{ 234 };
std::vector<int> z(5, {567});
for (int i = 0; i < 5; ++i) {
printf("x[%d] = %d y=%d z= %d\n", i, x[i], y[i], z[i]);
}
fflush(stdout);
}
output:
x[0] = 123 y=234 z= 567
x[1] = 0 y=0 z= 567
x[2] = 0 y=0 z= 567
x[3] = 0 y=0 z= 567
x[4] = 0 y=0 z= 567
No you were right to remove this code as processors isn’t a trivial type. So the line peaks::Processors processors[2] = {}; is correct.
I edited my crash log post as I initially thought it was a problem with the firmware; in reading the log I assumed (wrongly) that a large value was being passed by the module to the firmware. This is not the case. The problem is in the eurorack/peaks/modulations/multistage_envelope.cc file the trace is pointing to. This is due to the shape_ variable not being initialized in the void MultistageEnvelope::Init() method.
The line pointed to in the crash is
which uses shape_ as an index for lookup_table_table
LUT_ENV_LINEAR is defined in eurorack/peaks/resources.h
segment_ and phase_ are initialized in void MultistageEnvelope::Init()
The fix I have used is to add this code to the end of void MultistageEnvelope::Init() in peaks/modulations/multistage_envelope.cc
for (uint8_t i = 0; i < 8; i++) {
shape_[i] = {};
}
Any builders feel free to try the firmware code fix and let us know how you get on.
Nice! great analysis! On a trivial point, don’t you think my test, above, shows that initializing an array with {} doesn’t work (with the current microsoft compiler)? Of course always possible I made a mistake.
btw, it’s super easy to run your stuff under Valgrind, which will flag all sorts of uninitialized variable. You don’t need a special build or anything, just valgrind ./Rack
1 Like
I see what you’re trying to show with that code, I don’t get why suddenly the x and y arrays seem to have been “zeroized”. It’s been a few years since I’ve used MS compilers, always found them to be a bit wobbly, for want of a better term.