Crash with "Orange Line"

Plugins & Modules
21

Tested at 15h00 CET. No crash! Windows 11, VCV last version. Tested with different sample rates. I’ll test the different features this evening.

So, great job! Thank you so much :pray: Alain (Synthé Buel)

1 Like
22

this build works fine for me on Win11. no more crashes. :+1:

(side note: huge fan of your modules, thanks for the update)

1 Like
23

I am wondering a little bit of finding PatchMasterWidget in the stack trace

24

Hi again with the Orange Line Modules issue crashing Changed to 44.1khz from Auto and now Modules are not crashing Using WIn 10 64bit Weird ???

25

I am too.

Here’s my situation:

1: If I use the release build of the plugin (whether self-build or your build from GitHub) and load Morpheus into an empty patch, nothing happens.

2: If I try to load the “Moog Labyrinth” patch which uses Morpheus and PatchMaster mentioned by Alain in his OP, Rack crashes to the desktop with the Rack log as per my previous post Crash with "Orange Line" - #3 by Steve_Russell or there’s nothing in the log and GDB tells me

[Inferior 1 (process 11484) exited with code 03]
(gdb) bt
No stack.

3: If I run Rack in a GDB session with a debug build of the plugin and load Morpheus into an empty patch, Rack just hangs with high CPU and I have to Ctrl-C the GDB session to quit the process

GNU gdb (GDB) 15.1                                                                     
Copyright (C) 2024 Free Software Foundation, Inc. 

[snipped]
                                                                                                      
Reading symbols from Rack.exe...                                                       
(gdb) r                                                                                
Starting program: C:\Program Files\VCV\Rack2 Pro\Rack.exe -u . -d   

[snipped]
                                                                                       
Thread 13 received signal SIGTRAP, Trace/breakpoint trap.                              
[Switching to Thread 10756.0x2c50]                                                     
0x00007fff48811091 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll        
(gdb) q                                                                                
A debugging session is active.                                                         
                                                                                       
        Inferior 1 [process 10756] will be killed.                                     
                                                                                       
Quit anyway? (y or n) y

As noted from previous posters I’ve tried both 44.1kHz and 48kHz (my usual) sample rates; both to no avail.

Currently stumped here…

26

This reminds me of a very tough module bug that I tracked down a year or so ago. In that case, the crash was related to a specific module that was in the patch, but that module was never implicated in the crash log. Other innocent modules that were in the patch were implicated in seemingly random manner.

2 Likes
27

Oh yeah, I remember that case now that you mention it.

28

That call stack after Ctrl+C is normal for the debugger Ctrl+C break and doesn’t tell you anything about what’s happening in the app. You’d need to look at the call stacks for all the threads and see where it’s hung up.

When Rack crashes and there’s nothing in the log, it usually means that it crashed in one of the specialty threads in Rack like the thread servicing RTMIDI (there are several such threads). These specialty threads don’t have logging.

1 Like
29

What @k-chaffin is talking about is when one plugin corrupts memory, causing some other thing to crash.

1 Like
30

Ah OK didn’t know that. Thanks Paul.

1 Like
31

Yeah I realised that, I just happen to remember that thread, just not all the details without looking it up.