Right-click death

Plugins & Modules
1

When I right click and attempt to add a module, the whole thing crashes. Deleted my Squink product, still crashes. What do I do now? I looked at the log file, and I really don’t know what I’m looking for. Has anybody had the same problem?

2

The last 20 ish lines of the file, what OS are you running and what version of VCV Rack ?

3

Crashing in the Browser is not a very unusual problem, especially for beta/early-release plugins.

Some of us know what to look for. Copy and paste the last half of the log file inside triple-back-tick fences like this:

```
log snippet here
```

4

Although I have been dumb enough to push out something like this that crashes the module browser, I’m not aware of any issues like this in the last couple of years. Is there an issue I should know about?

5

Here is the last bunch of spewage from my log file: … [782.180 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace: 33: 0x0 32: 0x0 31: _C_specific_handler 0x771471cc 30: _chkstk 0x7715be00 29: RtlInitializeResource 0x7712fed0 28: KiUserExceptionDispatcher 0x7715b510 27: ZN4rack3app9SvgSwitch8addFrameESt10shared_ptrINS_6window3SvgEE 0x7feec59a110 26: ZN11EModeSliderC1Ev 0x7fef62e3516 25: ZN12SN_VCOWidgetC1EP6SN_VCO 0x7fef62f5890 24: ZZN4rack11createModelI6SN_VCO12SN_VCOWidgetEEPNS_6plugin5ModelENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEN6TModel18createModuleWidgetEPNS_6engine6ModuleE 0x7fef6305720 23: ZN4rack3app7browser8ModelBox4drawERKNS_6widget6Widget8DrawArgsE 0x7feeca11d60 22: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 21: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 20: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 19: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 18: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 17: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 16: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 15: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 14: ZN4rack2ui12ScrollWidget4drawERKNS_6widget6Widget8DrawArgsE 0x7feec5b00b0 13: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 12: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 11: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 10: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 9: ZN4rack6widget6Widget9drawChildEPS1_RKNS1_8DrawArgsEi 0x7feec5b7e70 8: ZN4rack6widget6Widget4drawERKNS1_8DrawArgsE 0x7feec5b7fe0 7: ZN4rack6window6Window4stepEv 0x7feec5b9eb0 6: ZN4rack6window6Window3runEv 0x7feec5ba8b0 5: ZN4rack6window6Window3runEv 0x7feec5ba8b0 4: ZN4rack6window6Window3runEv 0x7feec5ba8b0 3: ZN4rack6window6Window3runEv 0x7feec5ba8b0 2: ZN4rack6window6Window3runEv 0x7feec5ba8b0 1: BaseThreadInitThunk 0x76fe5560 0: RtlUserThreadStart 0x77143710 …

6

Since you deleted “Squink” (not that helpful because there are multiple plugins related to the name “Squinky”: Squinky Labs, SquinkTronix), that plugin (whatever it was) is clearly not the problem.

I’m having a hard time figuring out what module that is. Seems to be something named simply “VCO”, which isn’t helpful.

You’ll need to delete one plugin at a time until it stops crashing. The last one deleted is “probably” the culprit.

Might need to see your entire log file. This time, paste it between the triple back-tick fences (like I said before, and provided an example of what it looks like), so that the whole log doesn’t get mushed up into one line.

7

Looks like sn VCV Library - sn sn-vco

Delete that folder from your plugins folder and try again.

1 Like
8

Meh! sn-vco is mine … does it still crash if you remove it?

9

FWIW, most of the time a module crashing in the browser is a simple missing check for null module in the ModuleWidget subclass.

10

Thanks - let me check … yup, that’s quite probable - I didn’t realise a widget could be instantiated without a module.

11

You can also have Modules without ModuleWidgets (headless mode).

12

Ah, right, thanks … I’ll add checks for that too if it’s needed.

13

no one uses headless mode - I never got a complaint about not supporting it. But everyone notices when you crash the module browser - that’s bad. VCV library even rolled me back automatically the time I pushed that to the library.

1 Like
14

headless mode is cool and very efficient, never had a problem on a live situation with external controllers (I was on Linux, with es-9)

15

I’ve made some modules that don’t work right in headless mode.

16

@rubyfocu Can you please attach your log.txt file to this issue on GitHub:

17

Just to tidy this one away…

@Steve_Russell dug into the stack trace and it looks like it’s probably the 8Mode SoftSN module that’s causing the crash:

(I’ll attach the stack trace and these two threads to that GitHub issue)

2 Likes