OrestesOne module crashes VCVRack when opening another .vcv file

[rjsmith]

vcvrack-crash_log.txt

patches.zip

VCV Rack Pro 2.6.4 macOS ARM64 Sequoia 15.6.1

VCVRack intermittently crashes if OrestesOne module is included in an open .vcv patch with configured MIDi devices, and then you drag another vcv file onto the VCVRack UI.

Steps to reproduce:

1. Open attached one.vcv patch. Assign MIDI ports on the OrestesOne module, save patch.
2. Drag the attached two.vcv onto VCV rack window.
3. This may work OK no crash, or it may crash. If it does not crash, re-open one.vcv and repeat step 2 again.

Example vcvrack log.txt with additional logging statements:

[45.522 info src/OrestesOneWidget.cpp:308 step] Step
[45.524 info src/OrestesOneWidget.cpp:310 step] After Step
[45.554 info src/OrestesOneWidget.cpp:308 step] Step
[45.557 info src/patch.cpp:332 load] Loading patch /Users/<...>/Library/Application Support/Rack2/patches/OrestesCrash/two.vcv
[45.557 info src/rtaudio.cpp:207 closeStream] Stopping RtAudio Core Audio device 131
[45.588 info src/rtaudio.cpp:211 closeStream] Closing RtAudio Core Audio device 131
[45.588 info src/OrestesOneWidget.cpp:304 onRemove] Removing OrestesOneWidget
[45.588 info src/OrestesOneWidget.cpp:297 ~OrestesOneWidget] Unregistered map widget
[45.589 info src/OrestesOneWidget.cpp:220 onRemove] Removing MemDisplay
[45.591 info src/patch.cpp:347 load] Unarchived patch in 0.000197 seconds
[45.591 info src/patch.cpp:414 loadAutosave] Loading autosave /Users/<...>/Library/Application Support/Rack2/autosave/patch.json
[45.591 info src/engine/Engine.cpp:1463 fromJson] Creating module VCV Audio 2
[45.592 info src/rtaudio.cpp:112 RtAudioDevice] Creating RtAudio Core Audio device
[45.597 info src/rtaudio.cpp:179 openStream] Opening RtAudio Core Audio device 131: Audient iD14 (12 in, 6 out, 48000 sample rate, 256 block size)
[45.612 info src/rtaudio.cpp:189 openStream] Starting RtAudio Core Audio device 131
[45.622 info src/app/RackWidget.cpp:370 fromJson] Creating module widget VCV Audio 2
[45.627 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
/Applications/VCV Rack 2 Pro.app/Contents/MacOS/Rack: fatalSignalHandler(int) +0x28
/usr/lib/system/libsystem_platform.dylib: _sigtramp +0x38
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Users/<...>/Library/Application Support/Rack2/plugins-mac-arm64/RSBATechModules/plugin.dylib: RSBATechModules::OrestesOne::OrestesOneWidget::step() +0x50
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::ui::ScrollWidget::step() +0x1c
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::app::RackScrollWidget::step() +0x228
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::app::Scene::step() +0x1b0
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::window::Window::step() +0x544
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::window::Window::run() +0x28
/Applications/VCV Rack 2 Pro.app/Contents/MacOS/Rack: main +0x109c
/usr/lib/dyld: start +0x17bc

4. Repeat steps, but use the included midicat.vcv patch instead (uses the Stoermelder MidiCat module, on which OrestesOne is heavily based). Eventually, a similar crash will occur when dragging two.vcv onto the VCVRack UI:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libRack.dylib                 	       0x102314300 rack::widget::Widget::step() + 76
1   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
2   plugin.dylib                  	       0x108551280 StoermelderPackOne::ThemedModuleWidget<StoermelderPackOne::MidiCat::MidiCatModule, rack::app::ModuleWidget>::step() + 72
3   plugin.dylib                  	       0x10854e358 StoermelderPackOne::MidiCat::MidiCatBaseWidget::step() + 24
4   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
5   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
6   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
7   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
8   libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
9   libRack.dylib                 	       0x10230d220 rack::ui::ScrollWidget::step() + 28
10  libRack.dylib                 	       0x1022c8160 rack::app::RackScrollWidget::step() + 552
11  libRack.dylib                 	       0x1023142f4 rack::widget::Widget::step() + 64
12  libRack.dylib                 	       0x1022d4a94 rack::app::Scene::step() + 432
13  libRack.dylib                 	       0x102319b78 rack::window::Window::step() + 1348
14  libRack.dylib                 	       0x10231961c rack::window::Window::run() + 40
15  Rack                          	       0x10044a4b4 main + 4252
16  dyld                          	       0x193f0ab98 start + 6076

Known info:

• The crash only happens if the OrestesOneWidget's step() function's call to ModuleWidget:step() has not completed when the new .vcv file is dragged onto VCVRack. This was verified by adding INFO logs before and after the ModuleWidget::step() call - crashes only happen when the pre-"Step" log has printed but the post-Step log has not printed

void step() override {
        INFO("Step");
        ModuleWidget::step();
        INFO("After Step");

• By adding start/end logging into the step() functions of the individual widgets within the MidiWidget.hpp, it shows that the loading new patch happens during the execution of one of these step() methods. Once the load has initially finished, you can see the unfinished step() function is then completed (the "end step()" log line below). Then the crash happens.

[19.453 info src/components/MidiWidget.hpp:46 step] MidiDriverChoice step()
[19.453 info src/components/MidiWidget.hpp:56 step] MidiDriverChoice end step()
[19.453 info src/components/MidiWidget.hpp:101 step] MidiDeviceChoice -> step()
[19.455 info src/patch.cpp:332 load] Loading patch /Users/<..>/Library/Application Support/Rack2/patches/OrestesCrash/two.vcv
[19.456 info src/rtaudio.cpp:207 closeStream] Stopping RtAudio Core Audio device 131
[19.481 info src/rtaudio.cpp:211 closeStream] Closing RtAudio Core Audio device 131
[19.482 info src/OrestesOneWidget.cpp:304 onRemove] Removing OrestesOneWidget
[19.482 info src/OrestesOneWidget.cpp:297 ~OrestesOneWidget] Unregistered map widget
[19.482 info src/components/MidiWidget.hpp:172 onRemove] MidiWidget onRemove
[19.482 info src/components/MidiWidget.hpp:172 onRemove] MidiWidget onRemove
[19.482 info src/components/MidiWidget.hpp:172 onRemove] MidiWidget onRemove
[19.483 info src/OrestesOneWidget.cpp:220 onRemove] Removing MemDisplay
[19.484 info src/patch.cpp:347 load] Unarchived patch in 0.000252 seconds
[19.484 info src/patch.cpp:414 loadAutosave] Loading autosave /Users/<..>//Library/Application Support/Rack2/autosave/patch.json
[19.484 info src/engine/Engine.cpp:1463 fromJson] Creating module VCV Audio 2
[19.486 info src/rtaudio.cpp:112 RtAudioDevice] Creating RtAudio Core Audio device
[19.491 info src/rtaudio.cpp:179 openStream] Opening RtAudio Core Audio device 131: Audient iD14 (12 in, 6 out, 48000 sample rate, 256 block size)
[19.504 info src/rtaudio.cpp:189 openStream] Starting RtAudio Core Audio device 131
[19.514 info src/app/RackWidget.cpp:370 fromJson] Creating module widget VCV Audio 2
[19.544 info src/components/MidiWidget.hpp:111 step] MidiDeviceChoice -> end step())
[19.550 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
/Applications/VCV Rack 2 Pro.app/Contents/MacOS/Rack: fatalSignalHandler(int) +0x28
/usr/lib/system/libsystem_platform.dylib: _sigtramp +0x38
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Users/<..>//Library/Application Support/Rack2/plugins-mac-arm64/RSBATechModules/plugin.dylib: RSBATechModules::OrestesOne::OrestesOneWidget::step() +0x50
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::ui::ScrollWidget::step() +0x1c
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::app::RackScrollWidget::step() +0x228
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::widget::Widget::step() +0x40
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::app::Scene::step() +0x1b0
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::window::Window::step() +0x544
/Applications/VCV Rack 2 Pro.app/Contents/Resources/libRack.dylib: rack::window::Window::run() +0x28
/Applications/VCV Rack 2 Pro.app/Contents/MacOS/Rack: main +0x109c
/usr/lib/dyld: start +0x17bc

• The crash has never been observed if use the VCVRack File -> open menu to change the loaded vcv file.
• The crash does not happen if the OrestesOne module instance does not have configured MIDI devices
• This does not affect Pylades (with / without a configured OSC network connections)
• The crash happens once the patch with OrestesOne has been destroyed and the new vcv rack patch (with or without an OrestesOne module) is opened.
• MIDI-CAT does not crash (note that OrestesOne is largely based on the code of MIDI-CAT) (EDIT - actually it does - see above)

It seems that the OrestesOneWidget is not being destroyed properly when the first patch is unloaded, and then the crash happens when the new patch tries to step the (non-existent) OrestesOneWidget.

I added logs to the OrestesOneWidget destructor method, and added onRemove() methods to print when the widget and its children get removed which does print out when the open patch is unloaded

[95.976 info src/OrestesOneWidget.cpp:308 onRemove] Removing OrestesOneWidget
[95.976 info src/OrestesOneWidget.cpp:294 ~OrestesOneWidget] Destroying OrestesOneWidget
[95.976 info src/OrestesOneWidget.cpp:300 ~OrestesOneWidget] Unregistering map widget
[95.977 info src/components/MidiWidget.hpp:165 onRemove] Removing Electra Controller Electra Port 1
[95.977 info src/components/MidiWidget.hpp:165 onRemove] Removing Electra Controller Electra CTRL
[95.977 info src/components/MidiWidget.hpp:165 onRemove] Removing Electra Controller Electra Port 1
[95.978 info src/components/MidiWidget.hpp:165 onRemove] Removing Electra Controller Electra CTRL
[95.978 info src/OrestesOneWidget.cpp:220 onRemove] Removing MemDisplay

Crash stack dump (see attached macos full crash report):

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libRack.dylib                 	       0x10265c300 rack::widget::Widget::step() + 76
1   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
2   plugin.dylib                  	       0x10d764ac4 RSBATechModules::ThemedModuleWidget<RSBATechModules::OrestesOne::OrestesOneModule, rack::app::ModuleWidget>::step() + 196
3   plugin.dylib                  	       0x10d7622dc RSBATechModules::OrestesOne::OrestesOneWidget::step() + 20
4   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
5   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
6   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
7   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
8   libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
9   libRack.dylib                 	       0x102655220 rack::ui::ScrollWidget::step() + 28
10  libRack.dylib                 	       0x102610160 rack::app::RackScrollWidget::step() + 552
11  libRack.dylib                 	       0x10265c2f4 rack::widget::Widget::step() + 64
12  libRack.dylib                 	       0x10261ca94 rack::app::Scene::step() + 432
13  libRack.dylib                 	       0x102661b78 rack::window::Window::step() + 1348
14  libRack.dylib                 	       0x10266161c rack::window::Window::run() + 40
15  Rack                          	       0x100b224b4 main + 4252
16  dyld                          	       0x18bb4eb98 start + 6076

[rjsmith]

Looking at the code of the rack::widget::Widget::step function, it seems it does not do a safety check before it tried to access the child->requestedDelete member.

https://github.com/VCVRack/Rack/blob/v2/src/widget/Widget.cpp#L249-L267

Is it possible that in the use case of dragging a vcv file onto VCVRack, the engine is cleared down ready for the new patch to be loaded, which also destroys in the in-execution MidiWidget being step()-ed. , which then causes a memory violation when the Widget::step continues its loop to call the next child widget ?