After upgrade to v1, Issues with paramQuantity and ParamWidget

jeremy · May 21, 2019, 7:10pm

I used your script @baconpaul to get the SDK and I still get a crash on restart, sometimes a crash on add, and sometimes a gray bpm knob and crash on click. So I am having all kinds of fun. If I add modules with no knobs they seem to work fine. And, why does it work for you? I have no idea what is going on.

synthi · May 21, 2019, 7:28pm

I suspect it is something related to first initialization of paramQuantity when using old style code (using the rack0.hpp).
In some way the paramQuantity is not correctly inited and contains an invalid pointer.

jeremy · May 21, 2019, 7:30pm

I think the same thing. Any idea what I can do about that?

computerscare · May 21, 2019, 7:50pm

I’ve successfully migrated about half of the modules in my plugin to v1 without ever using the compatibility header. Maybe you could try skipping straight to the rack.hpp include for the module that is giving you trouble. It looks like your plugin uses a lot of shared components from your JWModules.hpp. I use a lot of shared components as well and I ended up commenting out everything I could to fix the errors one by one. Best of luck!

jeremy · May 21, 2019, 7:56pm

Ok I will try to move on to phase 2 and see if that helps. Thank you everybody.

Vortico · May 21, 2019, 8:03pm

Probably a good idea. I haven’t looked at this code yet, but it would be more straightforward to look at v1 API calls than rack0.hpp calls.

baconpaul · May 21, 2019, 8:19pm

Yeah sorry wish I could help more. I just started and stopped rack 10 times with a network using your simple clock and min max and had no crashes or problems.

jeremy · May 21, 2019, 9:02pm

I think that fixed my issue. Not crashing on restart anymore. Now on to fixing UI issues.

carbon14 · June 29, 2019, 3:00pm

I think the code in rack0.hpp is not thread safe. The deprecated version of createParam calls module->configParam from the ModuleWidget ctor. I’ve been struggling for a few weeks to port my code to v1, because I misread Andrew’s migration guide and I was doing exactly the same thing. But it should be called from the Module ctor, and I suspect that its not safe to do it from the ModuleWidget. I was getting corruption of ParamQuantity such that it’s module pointer was garbage.

Go straight ahead and do the phase 2 migration, but read it thoroughly and do what it says.

cclark2 · June 29, 2019, 4:08pm

I don’t think its a thread safety problem but an order-of-operation problem.

Module::configParam must be called before createParam; calling it afterwards allows ParamQuantity to point at deleted memory which may work by chance until the memory is reused.

carbon14 · June 29, 2019, 4:16pm

You might be right.

I’ve realised why I was doing it that way. I didn’t follow the phase 2 instructions for that part, because I’d already dealt with the deprecation warnings. And to do that, I’d simply replaced the deprecated call with exactly what rack0 does.

My fault: but if you are right, then rack0 can be fixed.

cschol · June 29, 2019, 6:29pm

Similar issues with RJModules. Note, that RJModules is still using the compatibility header. I recommended updating to the full API.

I used the signal trap in Rack to extract a backtrace, but it just points to ParamWidget. This is on Windows 10. I cannot reproduce this on Linux.

[0.296 fatal src/main.cpp:40] Fatal signal 11. Stack trace:
22: ZN4rack10appDestroyEv 0x4561c5
21: gai_strerrorW 0x757ac0
20: _C_specific_handler 0x32f07fd0
19: _chkstk 0x332b4660
18: RtlWalkFrameChain 0x33213730
17: KiUserExceptionDispatcher 0x332b34c0
16: ZN4rack3app11ParamWidget4stepEv 0x498776
15: ZN4rack6widget6Widget4stepEv 0x4a6782
14: ZN4rack6widget6Widget4stepEv 0x4a6782
13: ZN4rack6widget6Widget4stepEv 0x4a6782
12: ZN4rack6widget6Widget4stepEv 0x4a6782
11: ZN4rack6widget6Widget4stepEv 0x4a6782
10: ZN4rack6widget6Widget4stepEv 0x4a6782
9: ZN4rack2ui12ScrollWidget4stepEv 0x4a265e
8: ZN4rack3app16RackScrollWidget4stepEv 0x48a890
7: ZN4rack6widget6Widget4stepEv 0x4a6782
6: ZN4rack3app5Scene4stepEv 0x4914a4
5: ZN4rack6Window3runEv 0x4587ca
4: main 0x7a01e0
3: main 0x7a01e0
2: main 0x7a01e0
1: BaseThreadInitThunk 0x328b7960
0: RtlUserThreadStart 0x3327a250

RJModules · June 29, 2019, 6:50pm

Hey all. As Christoph mentioned, I’m having the same issue, tracked here: https://github.com/Miserlou/RJModules/issues/38 with a (mostly) workable repro.

Is there something I can check for in the step function to prevent this crash? I have too many modules to migrate everything to pure v1 without more effort that I can give, and I’d like to develop new modules on v1 instead.

Also, hi!

carbon14 · June 29, 2019, 7:01pm

I don’t believe there’s anything you can check for. This was exactly the same kind of back trace that I got. On Linux.

If you haven’t time to do the complete migration, step 2.10 should fix this, and you can still keep using rack0.hpp afterwards.

carbon14 · June 29, 2019, 7:14pm

I’ve posted an issue on github.

RJModules · June 29, 2019, 7:16pm

Hrm. Thanks.

$ a addParam | wc -l
     202

Does anybody have a script or something for this? 202 parameters across 51 modules… this is going to be incredibly tedious.

carbon14 · June 29, 2019, 8:00pm

I don’t have a script, I had a similar number of params

Edit each sources file
copy the createParam section.
change the method name in one copy
delete some parameters from one set
delete the other parameters from the other section
move the configParam section to the Module ctor.

The migration manual has some perl replacements that might help partway

Vortico · June 29, 2019, 10:02pm

Are you talking about Phase 2.10? There is a perl script in the writeup. https://vcvrack.com/manual/Migrate1.html