Latest builds of ACE, Bazille, Diva, Hive, Satin, Zebra 2/HZ (beta) crash on opening UI on Arch Linux

Post Reply New Topic
RELATED
PRODUCTS

Post

I am running a fully updated version of Arch Linux, where all of the mentioned U-HE plugs have been working before updating to the latest versions. Currently, the status is as stated below; I am guessing something common in the GUI code got introduced in the latest builds, as they all seem to be crashing in the same place.

The stack traces are from running the plugs in Carla, as that was the quickest way to systematically test all of them. I have tried them also in the latest versions of Bitwig, Renoise, and Reaper, and they all crash there as well.

When loading them into Carla, the plug GUIs are not opened initially, and I can then play the plugs and change parameters through the Carla interface, but as soon as I try to open the plug native interface they crash (logs below).

The stack traces below are from running the vst3 versions, but they all crash in similar ways for vst2 and clap.

Arch Linux is running glibc 2.40+r16+gaa533d58ff-2

I hope this information helps. Please let me know if you want me to do some additional tests.

Crashing
ACE v1.4.3
Bazille v1.1.3
Diva v1.4.8
Hive v2.1.2
Satin v1.3.3
Zebra 2 v2.9.4
ZebraHZ v2.9.4
Zebralette3

Working
Repro-1 v1.1.2
Repro-5 v1.1.2
Zebra 2 v2.9.3
ZebraHZ v2.9.3
Zebralette v2.9.3


Oct 22 20:42:30 machine systemd-coredump[58724]: [πŸ‘•] Process 52951 (carla) of user 1000 dumped core.

Stack trace of thread 52951:
#0 0x000079f031ea53f4 n/a (libc.so.6 + 0x963f4)
#1 0x000079f031e4c120 raise (libc.so.6 + 0x3d120)
#2 0x000079f031e334c3 abort (libc.so.6 + 0x244c3)
#3 0x000079eff44972b3 n/a (/home/user/.u-he/ACE/ACE.64.so + 0x2972b3)
ELF object binary architecture: AMD x86-64

Oct 22 20:43:51 machine systemd-coredump[59035]: [πŸ‘•] Process 58960 (carla) of user 1000 dumped core.

Stack trace of thread 58960:
#0 0x00007b0d580a53f4 n/a (libc.so.6 + 0x963f4)
#1 0x00007b0d5804c120 raise (libc.so.6 + 0x3d120)
#2 0x00007b0d580334c3 abort (libc.so.6 + 0x244c3)
#3 0x00007b0d1b09fa33 n/a (/home/user/.u-he/Bazille/Bazille.64.so + 0x29fa33)
ELF object binary architecture: AMD x86-64


Oct 22 20:44:42 machine systemd-coredump[59292]: [πŸ‘•] Process 59180 (carla) of user 1000 dumped core.

Stack trace of thread 59180:
#0 0x000077e2848a53f4 n/a (libc.so.6 + 0x963f4)
#1 0x000077e28484c120 raise (libc.so.6 + 0x3d120)
#2 0x000077e2848334c3 abort (libc.so.6 + 0x244c3)
#3 0x000077e23f163fd3 n/a (/home/user/.u-he/Diva/Diva.64.so + 0x363fd3)
ELF object binary architecture: AMD x86-64


Oct 22 20:45:22 machine systemd-coredump[59395]: [πŸ‘•] Process 59352 (carla) of user 1000 dumped core.

Stack trace of thread 59352:
#0 0x00007bb7cc6a53f4 n/a (libc.so.6 + 0x963f4)
#1 0x00007bb7cc64c120 raise (libc.so.6 + 0x3d120)
#2 0x00007bb7cc6334c3 abort (libc.so.6 + 0x244c3)
#3 0x00007bb786ebf013 n/a (/home/user/.u-he/Hive/Hive.64.so + 0x2bf013)
ELF object binary architecture: AMD x86-64


Oct 22 20:47:31 machine systemd-coredump[59837]: [πŸ‘•] Process 59542 (carla) of user 1000 dumped core.

Stack trace of thread 59542:
#0 0x0000785d4e2a53f4 n/a (libc.so.6 + 0x963f4)
#1 0x0000785d4e24c120 raise (libc.so.6 + 0x3d120)
#2 0x0000785d4e2334c3 abort (libc.so.6 + 0x244c3)
#3 0x0000785cfb2de3ba n/a (/home/user/.u-he/Satin/Satin.64.so + 0x2de3ba)
ELF object binary architecture: AMD x86-64


Oct 22 20:51:07 system systemd-coredump[60492]: [πŸ‘•] Process 59946 (carla) of user 1000 dumped core.

Stack trace of thread 59946:
#0 0x00007f111f8a53f4 n/a (libc.so.6 + 0x963f4)
#1 0x00007f111f84c120 raise (libc.so.6 + 0x3d120)
#2 0x00007f111f8334c3 abort (libc.so.6 + 0x244c3)
#3 0x00007f10bcaff4da n/a (/home/user/.u-he/Zebralette3/Zebralette3.64.so + 0x2ff4da)
ELF object binary architecture: AMD x86-64


Cheers,

/johan

Post

Hmm, we did update the dialogs recently to work more consistent on all platforms, that's the only significant change I can imagine that might lead to issues in some Linux distributions.

I'll create a ticket for this, but it might take a while.
Our main Linux guy is not available for some weeks.
And we are not testing our plugins on Arch Linux, as they are mainly built to support Ubuntu based Linux distributions.
But we'll look into it, if we can manage to set up an Arch Linux system.
That QA guy from planet u-he.

Post

It's either the dialogs.

Or it could also be related to the preset database. The database starts scanning for presets the moment the plugin GUI is opened. If the plugin cannot access or create the database due to permission issues, this might cause trouble.
That QA guy from planet u-he.

Post

You could create a new folder on your desktop and call it u-he-log.
Once the folder exists, reproduce the issue and immediately afterwards zip the u-he-log folder and send it to our support.
We could then check if there is anything suspicious being logged.
That QA guy from planet u-he.

Post

I did the log-thing you suggested and submitted the log-file to your support. Please let me know if there's anything else I can do to help figure out what's wrong!

Post Reply

Return to β€œu-he Linux support”