v1 builds but crashes Rack

[davephillips]

Greetings !

Here's the info you requested:

$ uname -a
Linux The6300 4.6.7-200.rt14.1.fc23.ccrma.x86_64+rt #1 SMP PREEMPT RT Sat Oct 1 16:06:12 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

And the output from glxinfo:

glxinfo.txt

I can also run a debug session if you need a gdb report. Btw, this kind of crash (open browser, crash Rack) is often the result of a NULL module in a custom widget. Anything like that in your code ?

Best regards,

Dave Phillips

[dizzisound]

So sad this project is abandoned due to the cross-platform inherent compilation intricancies!

Anyway, @davephillips I can't understand if the crash you experiment was the same to me, but I could rid off a crash when adding the modules, by wrapping the body of the step() member in BaseProjectMWidget, with a if (module) ... {} clause.

So, just as maybe-one-day-wanna-be-useful archive notes @korfuri Still I can build the v1 branch on Windows with MingW, passing a slight modified makefile, and using my custom arrangement of projectM. The libprojectM library is built in the process and successfully linked. So sorry I have no idea how to commit/share my configuration of the project, it seems to be so peculiar and not reproducible/automatable without manually tricking the original repo files. I suspect it's quite a "dirty" arrangement, yet it works on my system. May be I could upload a "freezed", archive project?

The only anomaly I experiment is the following: when opening the module browser, a new rendering window of the "windowed" module is initiated and pops up every time. Basically, I have to forget of this and let these child windows live as-is, without taking actions with it. Doing so, I'm still able to add both the "windowed" and the "embedded" versions of the module, switch the presets, connect audio/CV, etc. As already said, I only have to forget the floating windows, both the "extra" (initiated by the module browser) and the "legitimate" ones (initiated by dragging a windowed-module onto the Rack stage). By closing or minimizing these, the assert() macro in projectM::projectM_resetGL triggers the ungraceful exit from Rack.
Posting a screenshot of the thing.