Dark Panel related crash

Development
1

Hi Everyone !

I’ve made an update recently, adding dark panel to my modules (code on github)

I got a bug reported by two different people where one of the modules (Sinensis) randomly crashes at init. I’ve got 3 logs, all on Windows 10 x64. I haven’t been able to repro on my macbook m1.

They seem to crash when choosing the model, or shortly after.

[939.596 info src/app/Browser.cpp:93 chooseModel] Creating module NOI Sinensis
[939.597 info src/app/Browser.cpp:97 chooseModel] Creating module widget NOI Sinensis

log-1.txt (66.6 KB) log-2.txt (137.0 KB) log.txt (346.5 KB)

All res files have the same permissions (using ls -l), I’ve treated Sinensis file the same as I did for the others : copy the light mode, rename Name.svg to NameDark.svg, edit colors, then modify UI code

setPanel(createPanel(asset::plugin(pluginInstance, "res/Sinensis.svg")));
// to 
setPanel(createPanel(asset::plugin(pluginInstance, "res/Sinensis.svg"), asset::plugin(pluginInstance, "res/SinensisDark.svg")));

All of this might be a timely coincidence and the panel might have nothing to do with it (in which case I’d be happy to change the title)

Any advice on investigating this ?

2

Confirmed the crash happens on my Windows 11 pc when you select the module from the browser.

The log does not contain any useful info from the crash.

Normally browser crashes are caused by trying to access a module value that doesnt exist, but usually in those cases the browser crashes immediately on open and the log has a stack trace.

As you say, seems like the crash is on init of the model…

edit: and since the browser displays the dark panel svg without issues, seems unlikely to be the cause of the crash

I suggest to try debugging the module constructor, either with some debug statements, or a debugger if you want to set one up

image
image1350×652 161 KB

edit 2: actually, the crash only happened on the first try, now it works just fine, very strange

3

run it under address sanitizer or valgrind.

4

Smells like that toolchain issue where you up with mixed std libs and you usually die in a std:;string destructor.

5

It does sound like that. I used to have that problem all the time. My home builds were fine, but the official builds crashed. Wasn’t std::string that was my problem, it was other std:: stuff, like std:stringstream and exception try/catch. I ended up writing my own versions or not using them, depending…