I get frequent segmentation faults when trying to create a new drumkit or modyfing parameters in current Debian stable Hydrogen. Adding/deleting sample layers seems to have a high probability of crashing. It could be a race condition when one thread tries to access a buffer that has been deleted by another thread. This is what I get when running under gdb: Thread 7 "hydrogen" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffda63e700 (LWP 2158)] 0x000055555577720e in H2Core::Sampler::__render_note(H2Core::Note*, unsigned int, H2Core::Song*) () (gdb) backtrace #0 0x000055555577720e in H2Core::Sampler::__render_note(H2Core::Note*, unsigned int, H2Core::Song*) () #1 0x00005555557787da in H2Core::Sampler::process(unsigned int, H2Core::Song*) () #2 0x0000555555728490 in H2Core::audioEngine_process(unsigned int, void*) () #3 0x00007ffff556c01e in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0 #4 0x00007ffff556b7e8 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0 #5 0x00007ffff55830d0 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0 #6 0x00007ffff4aa0494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007ffff3d42aff in clone () from /lib/x86_64-linux-gnu/libc.so.6
Dear submitter, as the package hydrogen has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/952772 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
Hi Roberto, I recently adopted Hydrogen for Debian, and see that no one followed up on this bug. 0.9.7-1+b1 from Debian 9 (stretch) is the oldest supported release, but the oldest version I am able to test is 0.9.7-6, and I was not able to trigger this crash there. Would you please confirm if you can trigger this segfault in hydrogen 0.9.7-6 or newer? Without any communication I plan to close this bug in six months, or when Debian 11 (bullseye) is released. Thank you, Nicholas
Hi, thank you for adopting Hydrogen :) Yes, it still happens with 0.9.7-6 (not tried upstream git sources). Maybe the severity can be lowered, I've been using Hydrogen with the workaround of choosing samples in advance, never deleting layers when building an instrument, and it works. It seems that deleting a layer is the most risky task, probably when the sound is still playing. Can't you reproduce it? It only took a few seconds to crash it, just a minute before writing this email. If this only happens to me, we could close the bug, though I wonder why are only my computers triggering the crash :/
Dear Roberto, So sorry for the unreasonably long wait for a reply! I confess to taking a winter break from Debian around the time of your reply, and then I was negligent in following up on non-RC bugs. Sorry :-/ Reply follows inline: Roberto <roberto@zenvoid.org> writes: We now have the option of 1.0.1-3 on Bullseye (Debian 11) :-) When you have the time to upgrade to Bullseye, would you please update this bug with your experience. That sounds like an unnecessarily cumbersome workaround, and I agree that this bug is important :-) If two or more people could reproduce the crash then I'd say it was an RC bug. For what it's worth, I believe that a hard to reproduce crash is *always* an important bug. I'm not sure why it crashes your system but not mine. For what it's worth, here is the setup on the system I record with: Jackdbus + the PulseAudio jack bridge + custom 5.4 realtime kernel + Scarlett 2i2 (1st gen) + rtirq. I wonder if the reason you're able to trigger this issue (I agree with your assessment and hypothesis, by the way) is because your interface is taking slightly longer to process the packets/stream, leading to a race->crash rather than a benign race? If so, you have a great setup for audio bug hunting! :-D If you're comfortable installing individual packages from experimental, and you're also able to reproduce the crash with 1.0.1-3 in Bullseye, then would you please consider also testing 1.1.0~beta1-1~exp1 (from experimental) to see if it's also affected? If 1.1.0~beta1 is affected then we'll need to contact upstream without delay, in the hopes of getting the fix into the next stable release. Kind regards, and sorry again for taking so long to reply, Nicholas
Don't worry, I'm so used to the workaround that I'll miss it when the bug is fixed ;) Of course, I'll test it. I may need some time, though, until I find a good moment to upgrade computers... It's quite possible that my computer is taking a longer time, it's many years old and very slow compared to nowaday standards. I can also do this, thank you for your suggestions.