gibbonjoyeux / VCV-Biset

VCV Rack Biset modules library
GNU General Public License v3.0
42 stars 3 forks source link

Blank crashes Rack on windows 10 #21

Closed Petervos2018 closed 7 months ago

Petervos2018 commented 8 months ago

[6.836 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 22. Stack trace: 13: 0x0 12: raise 0x7ffce70cabe0 11: abort 0x7ffce70cf1e0 10: wassert 0x7ffce70cd210 9: ZN4rack3app10RackWidget17getCompleteCablesEv 0x7ffc88464ce0 8: ZN5Blank7processERKN4rack6engine6Module11ProcessArgsE 0x7ffc7f584f00 7: ZN4rack6engine6Module9doProcessERKNS1_11ProcessArgsE 0x7ffc88475230 6: ZN4rack6engine12EngineWorker3runEv 0x7ffc88470d60 5: atomic_flag_test_and_set_explicit 0x7ffcb6e1be00 4: pthread_create_wrapper 0x7ffcdece4c70 3: beginthreadex 0x7ffce70dae30 2: endthreadex 0x7ffce70daf80 1: BaseThreadInitThunk 0x7ffce6347330 0: RtlUserThreadStart 0x7ffce8202690

https://community.vcvrack.com/t/biset-blank-oh-my-what-a-module/21504/2?u=yeager

Got it when reopening a patch, so it crashes when I close rack, and I only find out it crashed after restarting Rack.

baconpaul commented 8 months ago

If it helps from looking at the rack code that assertbwill fire only if there is a widget which is a child of the cable holder which is not dynamic cast able to a rack cable widget

gibbonjoyeux commented 8 months ago

Thanks a lot to both of you !

That's weird cause I don't put anything directly in the cable container and the getCompleteCables() function is called on every process but asserts only when closing VCV. I will loop through the cables myself without this function. On top of that, it should avoid creating a new vector on every process and should be a bit lighter.

Hope it will fix this. Will push the correction this week ! Thank again

baconpaul commented 8 months ago

yeah it doesn't actually crash on my mac either.

I presume you've seen the bespoke cable animation too right?

Oh one other thing. I totally dig the look but had a couple of thoughts. lemme open a separate issue.