Yeah, exactly the same as I have seen… its quite irritating
So what I am seeing is rack widget Widget clearChildren → PurfenatorWidget → rack widget Widget requestDelete
So something is causing a crash when the purf widget is being destructed? But it doesn’t happen everytime, so possibly its a race condition?
I’ll keep trying to pin it down, if anyone has any ideas please do say something
interesting, did you add it and remove it from the patch, or never add it?
if you added it and removed it, it should have added and then removed the additional widget.
If you never added it, then the crash can be caused by the module loading in the browser (this is when the widget is constructed but the reference to the module is null, so could be significant
I never added it to a patch.
Opening the browser, closing it closing rack is guaranteed to make it crash on start up. ← NOT ;(
EDIT : I thought it was but it isn’t
I’d go peruse your code, but your plugin doesn’t show a source link, so I can’t help you there,
FWIW stack trace looks kinda like a double delete. As I understand how purfenator works, it injects a widget into Rack’s hierarchy outside of your module widget’s hierarchy, so I’d look into exactly how that widget gets destroyed relative to the destruction and unloading of your module dll.
Try and test it with only 1 engine thread, and with multiple threads. In Rack standalone and inside a DAW. Instrument especially the starting and stopping procedures with printf’s so you can see in the log where it gets to.
Run it under address sanitizer. It’s fairly easy.
Pretty sure this was the problem, I was trying to be clever in the draw widget, detect when the Purf module was removed then delete itself, but the module widget was also calling delete on the draw widget it inserts, in its destructor.
Dirty hack
Seriously,Is there an option to become invisible in the post stack?
Damn it… this was not the problem (or not the only problem), just got a crash on closing, looks to be the same 
[291.915 info src/context.cpp:27 ~Context] Deleting scene
[292.228 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
46: 0x0
45: 0x0
44: _C_specific_handler 0x7ffe76e0b1b0
43: _chkstk 0x7ffe785542f0
42: RtlFindCharInUnicodeString 0x7ffe784cd9d0
41: KiUserExceptionDispatcher 0x7ffe785533e0
40: ZN4rack6widget6Widget13requestDeleteEv 0x7ffdbf39ec40
39: ZN16PurfenatorWidgetD0Ev 0x7ffdb9ce3e50
38: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
37: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
36: ZN4rack3app7browser21ModuleWidgetContainerD0Ev 0x7ffdbf7f7d80
35: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
34: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
33: ZN4rack6widget17FramebufferWidgetD0Ev 0x7ffdbf39cfe0
32: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
31: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
30: ZN4rack6widget10ZoomWidgetD0Ev 0x7ffdbf826af0
29: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
28: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
27: ZN4rack6widget17TransparentWidgetD0Ev 0x7ffdbf827570
26: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
25: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
24: ZN4rack3app7browser8ModelBoxD0Ev 0x7ffdbf7fadb0
23: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
22: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
21: ZN4rack2ui16SequentialLayoutD0Ev 0x7ffdbf7effc0
20: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
19: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
18: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
17: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
16: ZN4rack2ui12ScrollWidgetD0Ev 0x7ffdbf397fe0
15: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
14: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
13: ZN4rack3app7browser7BrowserD0Ev 0x7ffdbf7f9710
12: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
11: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
10: ZN4rack3app7browser14BrowserOverlayD0Ev 0x7ffdbf7f7880
9: ZN4rack6widget6Widget13clearChildrenEv 0x7ffdbf39f1e0
8: ZN4rack6widget6WidgetD1Ev 0x7ffdbf39f340
7: ZN4rack3app5SceneD0Ev 0x7ffdbf37c1f0
6: ZN4rack7ContextD2Ev 0x7ffdbf3154b0
5: ZN4rack7ContextD2Ev 0x7ffdbf3154b0
4: ZN4rack7ContextD2Ev 0x7ffdbf3154b0
3: ZN4rack7ContextD2Ev 0x7ffdbf3154b0
2: ZN4rack7ContextD2Ev 0x7ffdbf3154b0
1: BaseThreadInitThunk 0x7ffe779f2560
0: RtlUserThreadStart 0x7ffe7850aa30
Ah… I think I was doing something stupid (obviously!)
I added a debug when the module widget tries to remove the draw widget in the destructor, and saw that it was calling the delete twice.
I guess once for the module in the patch, and once for the widget in the module browser.
But it shouldn’t call the remove for the module browser widget, because it shouldn’t have created one…
Anyway, I believe this is the fix, at least I haven’t been able to make it crash since making this change:
PurfSkiffWidget *skiffWidget;
becomes
PurfSkiffWidget *skiffWidget = nullptr;
Yes, that looks great!
Right, well I’d call that a successful Saturday dev session, time to wrap things up, record a demo video and send the new build… Not sure if I’ll get another release out this year, so Happy Holidays everyone!
excited to try this. thanks!
Well… that was nice and quick 
This is so awesome Dan! Thank you for the hard work. Another vote for multiple skiffs, that would be such a cool way to work in VCV. Kind of like saved selections, but mini skiffs.
Is there a way to move the background image? Currently it’s forced to be centered, isn’t it? (Just asking. I can easily redraw the backdrop PNG…)
The background image is drawn to screen space rather than rack space, so yes if you want something in a particular location, the easiest way would be to make an image the same size as your screen.
I could potentially add controls for x and y offsets for the image if there are other users that would want that?
