After upgrade to v1, Issues with paramQuantity and ParamWidget

Development
1

Issue 1

I can add my module just fine but after stopping rack and restarting rack crashes with the following line in the crash report: rack::app::ParamWidget::step() + 21 (ParamWidget.cpp:113)

Issue 2 I have a custom knob which points to a label and updates it. When I try to reference the paramQuantity to get the value rack crashes with this: BPMKnob::formatCurrentValue() + 18 (SimpleClock.cpp:109)

Here is my v1 source:

Is there something I am missing about param widget or param quantity???

1 Like
2

For (1), can you run Rack in a debugger (like gdb or lldb) and report the backtrace (bt)?
Same with (2).

3

I tried to build and run your v1 but you havenā€™t checked in a plugin.json so I couldnā€™t. If you could check that in on your V1 branch Iā€™d be happy to give it a try. Others probably more useful than me tho.

I see you already check for null against the paramQuantity which is the first thing I thought. I had some edge cases with module being null I had to deal with which took a turn or two.

4

@Vortico i will have to figure out how to use gdb, yay.

@baconpaul I pushed up plugin.json since i accidentally ignored it.

1 Like
5

Run gdb ./Rack. Type run at the prompt. When it crashes, type bt. Same for lldb on Mac.

6

OK! Iā€™m headed out to an afternoon BBQ but got it to build. It cores out as soon as I open the module browser. My guess is that SimpleClockWidget is dealing improperly with a null module somewhere, probably where you bind your label to the knob. You may want to check module != null before you do that bind. So like ā€˜if module clock->connectLabel(bpmKnob)ā€™ but I didnā€™t rebuild with that change

Hereā€™s the trace

(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010097a792 plugin.dylib`BPMKnob::formatCurrentValue() + 18
    frame #1: 0x0000000100979e65 plugin.dylib`SimpleClockWidget::SimpleClockWidget(SimpleClock*) + 1093
    frame #2: 0x000000010097aa21 plugin.dylib`rack::plugin::Model* rack::createModel<SimpleClock, SimpleClockWidget>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::TModel::createModuleWidgetNull() + 33
    frame #3: 0x00000001000a6b56 Rack`rack::app::ModelBox::createPreview() + 230
    frame #4: 0x00000001000a3f5e Rack`rack::app::ModelBox::draw(rack::widget::Widget::DrawArg
7

Yes, Iā€™d guess the same thing.
See phase 1.9 of https://vcvrack.com/manual/Migrate1.html, and make sure that SimpleClockWidget and BPMKnob are checking if (module) ..., since Module Browser gives your ModuleWidget a NULL module.

8

I went through and did a lot of that already. Must be I am missing something. I have no issue with the module browser.

9

On my Mac it crashes in the module browser every time. Perhaps you are reading corrupt memory successfully in the module browser on your platform and just dying later?

If I get some post bbq time I will see if I see anything!

10

Ok thank you. I will keep messing with it.

1 Like
11

pushed v1 up again with a null check for module inside the knob. This seems to help one issue. Still messing with my other issue - when rack restarts with the clock loaded it crashes right away.

0   com.vcvrack.rack              	0x000000010909cfe5 rack::app::ParamWidget::step() + 21 (ParamWidget.cpp:113)
1   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
2   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
3   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
4   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
5   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
6   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
7   com.vcvrack.rack              	0x00000001090b1b94 rack::ui::ScrollWidget::step() + 20 (ScrollWidget.cpp:39)
8   com.vcvrack.rack              	0x000000010909fca4 rack::app::RackScrollWidget::step() + 676 (RackScrollWidget.cpp:75)
9   com.vcvrack.rack              	0x00000001090b5c99 rack::widget::Widget::step() + 169 (list:367)
10  com.vcvrack.rack              	0x00000001090a44b1 rack::app::Scene::step() + 593 (Scene.cpp:68)
11  com.vcvrack.rack              	0x0000000109070e81 rack::Window::run() + 1121 (window.cpp:369)
12  com.vcvrack.rack              	0x000000010905d46b main + 1179 (main.cpp:174)
13  com.vcvrack.rack              	0x0000000108ff5034 start + 52
12

is a crash due to the use of a NULL module in a custom widget;
best fast solution put a guard on custom widgets creation when module is NULL

13

I just stumbled into the same issue with a custom widget:

Thread 1 ā€œRackā€ received signal SIGSEGV, Segmentation fault. 0x00007fffec006494 in HammDisplay::draw (this=0x17ddba0, args=ā€¦) at src/AModal.hpp:149 149 unsigned int idx = module->idx;

where the issue is that module is NULL. I donā€™t know if it is of any help to other people here, but to improve the drawing in the module browser I draw the background graphics of my widget before checking that module is NULL and returning. The appearance in the module browser wonā€™t be totally right, but at least better than nothingā€¦

14

Just sent a pull request which gets your modules at least not segfaulting with V1.0 on my mac. I can also bind my LFO to your bouncing sprite panel and your sprite does indeed bounce. I donā€™t know how to test the rest of the modules.

Iā€™m fine to assign copyright on my diffs to you if you want to merge them directly if such a thing matters to you. Lemme know over on GitHub. Alternately you can reject my PR and just implement it. Basically when you return a string from something that checks for null, make sure to return a string if it is null etcā€¦ Turning off deprecation warnings and looking at remaining warning got me there. You were 99% of the way there.

1 Like
15

at work now, will look at this later, thank you for your help

1 Like
16

Still having the same exact issue. When I restart rack it crashes with the trace i listed above. @baconpaul can you try adding a clock, closing down rack. and restarting rack and see if it crashes?

Edit: I think this happens with all my modules.

17

Using the branch from my PR last night, I can start up rack, load your simple clock, quit, and restart, and quit, and restart over and over. No problem.

Wanna push your code again and Iā€™ll take a peek? I donā€™t have much time next day or two unfortunately.

On my mac using GitHub hash 02626925617a32b8d7dcfcdcf53ff07d7a4d4844 I can build it and load your modules fine with V1. Load unload, restart, over and over, etcā€¦

They look pretty cool actually!

18

thank you again, well this is frustrating, i guess i need to rebuild rack or something

iā€™m stuck

i see there are rack updates, pulling and makingā€¦

19

Iā€™ve been using the rack binaries for v1 for sdk and runtime since the weekend. I have a little bash script that downloads them and sets the path and runs and everything including making user dir and running rack with the right args and stuff. If you want thatā€™s in GitHub.com/surge-synthesizer/surge-rack in the scripts directory. Should be straight forward if you know bash

Are you on Mac? I could also try windows 10 or linux if you want but not now - Iā€™m headed to dinner.

20

I am fine with bash. I am on a mac. I will check out buildutil script. Maybe I will have less issues that way.