Encountered a GUI hang after a while on Linux with Speedrum demo

[elcalen]

Hi! I was trying out Speedrum in demo mode today for the first time. I noticed that after a few minutes of playing around with various controls, the GUI, and my entire DAW, suddenly freezes. Sound still keeps playing, it doesn't appear to be using abnormal amounts of CPU, but I have to force quit the DAW. This has happened a few times now, with both the VST2 and VST3 versions. Couldn't spot any meaningful messages in logs.

I'm on Debian Bullseye, with Gnome 3.38. Host is Reaper 6.34.

[apisonic]

Thanks for reporting it.
Latest version, 1.0.6? You can check it in About page if you click on a Speedrum logo.

[elcalen]

Right, forgot to mention that. Yes, it is 1.0.6, downloaded yesterday.

[elcalen]

I did a little more testing, and it seems I can most reliably trigger a crash by repeatedly dragging pads with samples around to swap their positions. (I can't say for sure that that was the case with every freeze I had previously, but I recall that at least a couple times it did in fact happen when I was dragging pads.) Sometimes it freezes Reaper like I described above, but now sometimes I've also had it just segmentation fault and exit.

[apisonic]

Thanks, that should narrow down the search. Any additional info is welcome

[elcalen]

OK, I took it for another quick spin. Tried stuff like loading in lots of samples by dragging from the browser, clicking on a bunch of pads, or rapidly loading new samples into a pad using the next/previous/random sample buttons, but nothing unusual appeared to happen. Seems like the only way I can reliably get it to crash is by dragging pads around. In fact, after I've spent a while doing that other stuff, trying to swap pads by dragging often seems to cause a crash almost instantly. With a fresh instance it can sometimes take a while.

In terms of hardware, if relevant, I'm on a 6th gen i3, 8gb ram, Nvidia 1050 (with proprietary driver).

PS. While testing, I noticed that the next/previous sample buttons aren't proceeding in alphabetical order.

[apisonic]

I tried it in VirualBox with 4Gb of ram, Debian Bullseye, with Gnome 3.38, Reaper 6.34... and I can't reproduce the crash, all is working as expected
I don't have any spare hardware available right now... If you have time, can you test it on your hardware but with different distribution?

As of next/previous alphabetical order, you're right, it's not sorted on unix... thanks for reported it.

[elcalen]

I don't really have a setup to easily test different distros right now. Though I do have access to a laptop running Ubuntu 20.04 that I can maybe try later. In the meanwhile, I tested with a different host (Carla), and it also segfaulted after a bunch of dragging pads around. So I think I can say it is likely not a problem with Reaper.

I looked at /var/log/syslog again, and while I didn't see any output for the times Reaper simply froze, there are some entries from when segfaults happen, but they seem to vary from time to time. Here are the entries for the couple most recent crashes:

Code: Select all

kernel: [21435.986798] carla[7165]: segfault at 139000000ff ip 00007f699e756615 sp 00007f699f7fdce0 error 4 in Speedrum.so[7f699e34c000+a30000]
kernel: [21435.986806] Code: c4 0f 1f 40 00 41 54 55 48 89 fd 53 48 8d 5f 18 49 89 f4 48 89 df e8 ea 98 ef ff 44 8b 45 4c 48 8b 7d 40 45 85 c0 7e 2c 31 c9 <4c> 3b 27 48 8d 47 08 75 19 e9 ad 00 00 00 0f 1f 44 00 00 48 89 c7

Code: Select all

kernel: [21582.166281] traps: carla[7211] general protection fault ip:7fd51eca6615 sp:7fd51e29fce0 error:0 in Speedrum.so[7fd51e89c000+a30000]

[apisonic]

Ok, thanks.
Does crash happen when the host is playing, or it doesn't matter if it is playing or not?

[elcalen]

Host's play state doesn't appear to matter. I can trigger it just by starting up Reaper with an empty project, creating a new track with a Speedrum instance, loading a couple samples and dragging the pads around for a while. I *think* it has to be actually swapping the location of two samples. I just tried repeatedly dragging a single sample to empty pads, and couldn't seem to trigger the crash that way.

One other unrelated bit of Linux feedback: I just noticed that an Apisonic directory has been created in my home directory, containing the file "Speedrum.triggermaps". I think it's better practise on Linux to store configuration files in a hidden directory, so the user's home directory doesn't become needlessly cluttered. And actually, it looks like there already is an Apisonic directory under ~/.config, containing the file "Speedrum.settings". So has the other directory been created by error? I imagine all the configs should go in the same place...

For what it's worth, I'm still using Speedrum in demo mode. But I have to say, even with this crash issue, I'm still quite tempted to buy the full version. It's definitely one of the most impressive samplers of its kind that I've seen on Linux...

[elcalen]

OK, so I tested with a laptop running Ubuntu 20.04 LTS, with a fresh Reaper 6.35 install, and was able to replicate the crash a couple times exactly as described (dragging to swap pads after messing around with the plugin for a while, resulting in either a freeze or segfault). That machine has a Pentium Gold cpu, 8gb ram, integrated Intel gpu, also running Gnome.

I guess this at least confirms that the issue is not due to something messed up in my main PC, or something specifically in Debian Bullseye... What both these machines have in common is Intel hardware and Gnome. I don't currently have easy access to test on other hardware...

EDIT: I tried booting into Compiz instead of Gnome, and was still able to trigger a freeze. So I don't think Gnome is the culprit here.

[apisonic]

Ok, I was able to reproduce the crash, thank you for your info, I'll see why it happens.

About config files, all should go under .config, probably bug, thanks for reporting it.

[apisonic]

You can test the latest update and see if you will get a freeze/crash.

[elcalen]

Awesome. While I haven't had time to very extensively test it, during a little while of messing around with it just now I wasn't able to trigger a crash, so it looks promising. And it looks like the other issues I reported with configs and sorting have also been fixed. Thanks!

PS. I have now bought the full version of the plugin, by the way. Thanks for supporting Linux! While the native Linux plugin scene is constantly improving, there's still a lot of areas where there isn't a lot of choice, and having access to a well featured sampler like this is definitely a nice addition.

[apisonic]

I'm glad to hear that, thanks.