crash reloading a reaper project on ArchLinux

[trummerschlunk]

Thanks for your great work!!

On reaper/linux/arch cardinal works as far as I could test, but I cannot reload projects saved with a cardinal instance. Reaper crashes on load.

I am sorry for not providing logs. Where would they be?

Thanks!

[falkTX]

See if the github action builds fix the issue, other people running arch have reported crashes that do not appear when using the pre-compiled builds.
Let me know how they work.

[trummerschlunk]

Thanks, will try...

[jypma]

I can confirm the issue, and the workaround works for me (arch linux).

Cardinal built using cardinal-git from AUR:

• Using carla 2.4.1-2, saving a setup with Cardinal works, but loading it again crashes Carla.

Cardinal built from github actions saves and loads fine in Carla.

Is the mysterious SYSDEPS=true perhaps the cause behind it? The AUR build doesn't seem to do anything fancy otherwise.

By the way, the built-it "Save as..." inside Cardinal itself is a no-op for me. Is that as intended? (loading of Rack2 patches works fine.)

[falkTX]

Just tried SYSDEPS=true here, no crash on save and loading with Carla.

So I suspect crash comes from somewhere else.

[trummerschlunk]

How do you build/install from github actions (on arch)? I really tried to figure it out, but I find nothing... Sorry, probably a very noob question.

Thank you

[jypma]

1. Pick the top link on the github actions page. That'll be the most recent commit.
2. On that page (e.g. here), scroll all the way down to "Artifacts"
3. Pick the artifact that matches your architecture (on arch linux, that's probably the one with x86_64 in its name)
4. Extract that anywhere in your home folder
5. Place symlinks to the .lv2 directories from ~/.lv2, and make sure ~/.lv2 is in LV2_PATH (although I think it is, by default)

[trummerschlunk]

Thanks indeed :)

[trummerschlunk]

So yes, falkTX, same behaviour as in this issue with the arch packaged version here.
The latest version from github actions works fine with reaper and bitwig as vst and lv2.

[falkTX]

so we need someone to build cardinal with DEBUG=true and get a backtrace.
is this something you can do?

[trummerschlunk]

oh my, no. I am a musician (still) ;)

But David, who packaged it for arch might be able to do it... I'll ask him...

[dvzrv]

I have rebuild cardinal and ardour with additional debug package.

Here is the backtrace of when I'm attempting to load a session with an instance of cardinal in it:

#0  0x00006ecadf11534c in __pthread_kill_implementation () at /usr/lib/libc.so.6
#1  0x00006ecadf0c84b8 in raise () at /usr/lib/libc.so.6
#2  0x00006ecadf0b2534 in abort () at /usr/lib/libc.so.6
#3  0x00006ec9b17b9caa in  () at /usr/lib/lv2/CardinalSynth.lv2/CardinalSynth.so
#4  0x00006ec9b21c319b in  () at /usr/lib/lv2/CardinalSynth.lv2/CardinalSynth.so
#5  0x00006ecade994776 in __archive_read_filter_ahead () at /usr/lib/libarchive.so.13
#6  0x00006ecade9a0565 in  () at /usr/lib/libarchive.so.13
#7  0x00006ecade994776 in __archive_read_filter_ahead () at /usr/lib/libarchive.so.13
#8  0x00006ecade99ed39 in  () at /usr/lib/libarchive.so.13
#9  0x00006ecade9963b5 in archive_read_open1 () at /usr/lib/libarchive.so.13
#10 0x00006ec9b21d30b1 in  () at /usr/lib/lv2/CardinalSynth.lv2/CardinalSynth.so
#11 0x00006ec9b177884f in  () at /usr/lib/lv2/CardinalSynth.lv2/CardinalSynth.so
#12 0x00006ec9b178171c in  () at /usr/lib/lv2/CardinalSynth.lv2/CardinalSynth.so
#13 0x00006ecadf80af72 in lilv_state_restore () at /usr/lib/liblilv-0.so.0

trace.log
trace_with_threads.log

[falkTX]

Found the culprit, ArchLinux uses -D_GLIBCXX_ASSERTIONS build flag which adds a bunch of assertions on STL classes.
Seems some code is using std::vector incorrectly, found at least 2 places where it happens.
See #156 for the dedicated ticket for it.

In the mean time e9dc1c8 has a workaround, simply skipping the assertions that trigger the crash.
Since this makes Cardinal behave like all others, I treat it as fixed. even though code should be fixed/improved to handle these STL assertions, it is just that it all comes from code we import (Rack itself)

We should report the issue to VCV, anyone up for that? :)