Closed SteveRussell33 closed 3 years ago
That's very weird, I'm on win10 also here, and I can't get this bug. I've sent a build to another windows tester and it worked ok, and another tester in Mac has confirmed it works, so this is puzzling. Can you send me your build please and I will install it and try? Perhaps one thing just to be sure, and you should not have to do this, but can you do a "make clean" before building?
Update: another Win tester showed it generally working, but when setting dark as the default, they had the white knobs on BlackHoles, so perhaps there is something wrong somewhere in the code.
Ok, I think I see the problem, I'll push a fix soon.
Hey Marc, Same problem. Built ac1f453 from a fresh repo clone. Tried your v2.2.2 build from Releases - same thing. Here's my local build: Geodesics_ac1f453_win10.zip
Your build is working on my end, so my guess is that one of your plugins is not beta.1
To be completely sure it's Geodesics, could you please try moving all your plugins except Geodesics to a temporary folder, and then try to see if Geodesics alone crashes? I've sent the plugin to Omri, Pyer, Steve, Latif, Georg and with me that's 6 installs (4 win, 2 mac) that seem to not crash, so it's quite a head-scratcher!
I've done this using Geodesics alone, and I still have the same problem. I would think that means it's something my end, but I have no idea what! I've even done a complete uninstall then reinstall of Rack2, same problem...
Very strange, not sure what to suggest next :-( Perhaps we can wait and see if anyone else gets the problem.
One thing you could try is to checkout the version before I made that module browser improvement.
try to git checkout bbf2672
and build this, I'll be curious to see what that reveals.
https://github.com/MarcBoule/Geodesics/commit/bbf2672b8e0e5d14f8cdd104f07e998d52c6fcca
That's the commit I've gone back to, that build is good, no problems at all. It's with commit 77bc307 onwards that I'm getting the problem.
Ok, I'll see if I can spot the issue, thanks for this!
Just out of curiosity, is Impromptu working correctly?
Ok, sorry to pester you with this, but as you can probably tell, I hate bugs! I believe I have spotted the issue. Can you try the head commit please?
Same problem mate. You're not pestering, would like to help get this fixed - your plugins are some of my faves. Impromptu works fine - tested with Geodesics/Impromptu/MindMeld together - it's definitely Geodesics from 77bc307
Ok, I think it could possibly have to do with parentheses vs operator precedence and how they are interpreted in the different compiler versions. This is a very minor change, but worth taking at shot at it, just to rule it out if ever it's not it. Thanks so much for your patience with this! We'll get to the bottom of it I'm sure.
I've done more testing with various combinations of plugins (all built with SDK beta 1) and now on occasion get this error log:
[306.009 fatal adapters/standalone.cpp:60 fatalSignalHandler] Fatal signal 22 SIG. Stack trace:
37: 0x0
36: raise 0x7ffd8729abe0
35: abort 0x7ffd8729f1e0
34: wassert 0x7ffd8729d210
33: ZN4rack6widget17FramebufferWidgetD0Ev 0x6faa9b90
32: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
31: ZN4rack6widget6WidgetD1Ev 0x6faabf30
30: ZN4rack6widget10ZoomWidgetD0Ev 0x6ff25910
29: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
28: ZN4rack6widget6WidgetD1Ev 0x6faabf30
27: ZN4rack6widget17TransparentWidgetD0Ev 0x6ff26320
26: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
25: ZN4rack6widget6WidgetD1Ev 0x6faabf30
24: ZN4rack3app7browser8ModelBoxD0Ev 0x6fefd150
23: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
22: ZN4rack6widget6WidgetD1Ev 0x6faabf30
21: ZN4rack2ui16SequentialLayoutD0Ev 0x6fef2aa0
20: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
19: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
18: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
17: ZN4rack6widget6WidgetD1Ev 0x6faabf30
16: ZN4rack2ui12ScrollWidgetD0Ev 0x6faa4970
15: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
14: ZN4rack6widget6WidgetD1Ev 0x6faabf30
13: ZN4rack3app7browser7BrowserD0Ev 0x6fefb950
12: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
11: ZN4rack6widget6WidgetD1Ev 0x6faabf30
10: ZN4rack3app7browser14BrowserOverlayD0Ev 0x6fef98c0
9: ZN4rack6widget6Widget13clearChildrenEv 0x6faabdc0
8: ZN4rack6widget6WidgetD1Ev 0x6faabf30
7: ZN4rack3app5SceneD0Ev 0x6fa88e70
6: ZN4rack7ContextD2Ev 0x6fa28560
5: ZN4rack7ContextD2Ev 0x6fa28560
4: ZN4rack7ContextD2Ev 0x6fa28560
3: ZN4rack7ContextD2Ev 0x6fa28560
2: ZN4rack7ContextD2Ev 0x6fa28560
1: BaseThreadInitThunk 0x7ffd86287020
0: RtlUserThreadStart 0x7ffd8
I'll have another go with your latest 50309d1 commit and report back here. I'm starting to think there might be a bug in the module browser itself when trying to display a large collection of modules - I have over 2700 for v1! It's weird this started with that particular Geodesics commit...
Oh man, nope 50309d1 no good... If I go back to my bbf2672 build all 720 modules in my test (I could add more!) render in the browser. Although sometimes I get the error log above on exit.
Hmm, weird. So the latest version did not fix things, and then when you build the last known good version (bbf2672), you sometimes get an error on exit.
Very strange, unfortunately that stack trace has no identifying information on which module/plugin could have caused the crash.
If you're up for it, it would be great to try the test with just Geodesics present in the plugin folder (laster version), and run it in the debugger, this may reveal more info.
pacman -S mingw-w64-x86_64-gdb
gdb
make debug
run
and then you do the steps needed to make it crash. Then back in the terminal, after it has crashed you can type "bt" for a backtrace. I don't know if you have used the debugger before, but things run more slowly in there, but sometimes the crash log can be more informative.
P.S. Strangely I can't seem to quit the debugger as the commands I used to do ("quit") no longer seem to work, so for now I just close the terminal and open a new one ;-)
Yeah I've used GDB before, I should probably have started with it in the first place...
Ran two tests: first with just the debug Geodesics DLL from the last good commit. No problem. Process exits normally. second test: used the debug DLL from the latest commit, problem occurs. I occasionally get this:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x000000006f9f8247 in nvgDeleteImage () from /c/Program Files/VCV/Rack2 Pro/libRack.dll
Ok, that's good to know, it must have something to do with how my dark panels are handled in the module browser. To summarize the latest change, I wanted the module browser to show the dark panels when the users choose dark as default. In the last working commit before the bug started happening, the modules are always showed in their light color theme, irrespective of that defaut choice. In the newer commits that crash, it tries to manage those color themes for the module browser.
I've prepared a new approach to this, which should be radically different in its internal workings, so I'll be eager to see if there's a difference. If you want to pull the head commit and try, I hope this will do it.
If not, then it may be interesting to check a few other things if possible:
Geodesics.json
, which should be in the root of your active Rack directory? I'm happy to report that your latest commit f4fa94a is much better thean the previous ones. The problem still occurs when I load plugins that result in more than ~400 modules in the browser. I'm leaning toward it may be something to do with my machine - a 6 year old laptop - I did update the AMD drivers: Renderer: ATI Technologies Inc. AMD Radeon(TM) R5 Graphics OpenGL: 4.6.14831 Compatibility Profile Context 21.5.2 27.20.20903.8001
Geodesics.json
simply contains { "darkAsDefault": true }
[markdown formats this as one line for some reason]
I've tried this with having the light panels as default, makes no difference.
The same problem occurs if Rack is using 1 or 2 threads, using 3 tends to slow down a bit too much to tell whether it's the browser or the machine, so I tend to use 2 threads esp. if I'm patching.
I find it weird that I had no problems until I used Geodesics 77bc307 with Rack2 Pro beta 1. I've gone back to the last good commit for the time being, simply because you've not updated any features/DSP. I might try the Free edition of Rack2 to see whether I can replicate the problem there. I'm thinking this might be a worthwhile endeavour as most Rack users will be using that edition. Thoughts?
Ah, alas, "much better" is indeed better, but it looks like it's still not solved :-(
So the problem occurs when your module browser contains 400+ modules, but if you have just Geodesics (or a small number of plugins), then if I understand correctly, the crash now never happens whereas before you could still get the crash even with just Geodesics installed?
But yes, I would try the free version for sure, any further data points can definitely help us. And if ever you have access to another windows PC/laptop, it would also be interesting to see if the same set of plugings (the exact same setup actually), will give you the crash there also.
In a sense it almost sounds like it could be a memory issue, but that shouldn't really truly be the case.
This issue is making me nervous now, haha! ;-) https://community.vcvrack.com/t/crash-when-opening-plugin-menu/14787
So the problem occurs when your module browser contains 400+ modules, but if you have just Geodesics (or a small number of plugins), then if I understand correctly, the crash now never happens whereas before you could still get the crash even with just Geodesics installed?
Correct.
I'm using your latest head commit aa3cb4b now as it seems to not make a difference if I use that build or the last good build bbf2672
When I have time later this week I'll create a Rack2 Free installation with the same set of plugins (507 modules now!) and report back here, to test whether there's any difference between editions.
I'm still leaning, however, that it's my machine; as I've been trying to get Rack.exe
to run as a higher priority process and not the Low setting that Windows gives it. I'm researching how to change a process's priority permanently so I can run Rack2 from a shortcut and not have to do anything manual after rack starts up. But I'll do whatever works for me.
Ok, let me know how your investigation goes :-)
Seems I've figured it out Marc! Using both a shortcut to start Rack at a higher process along with turning down the View -> Frame rate setting to 30Hz, the browser loads every module perfectly. Still seems strange that I started having a problem with the browser rendering with that particular build. Still not sure what happened there... Anyway, all is good back in Rack land! :) Sorry to be a bother - testing software is still fun after all! Thank you for your time and efforts - I really enjoy looking at your code and would like to take another opportunity to praise you for your outstanding modules.
Cheers
Great news, glad you've got it working! It's still strange that your priority and framerate settings stop the crash from happening, I guess there's still something weird in all of this somewhere, but seems like this mystery is best left alone I guess, haha :-) Thanks for the kind words, and happy patching!
Commit 77bc307e4ad340d51b5d7fc35ea411b524a9c92d built with SDK beta 1, tested with Rack2 Pro beta 1. No log file.