segmentation fault (core dumped)
ianhundere opened this issue · comments
This was discovered when implementing AH+FX whereby if I change inputs/outputs in my daw's (bitwig) settings I get the following output:
❯ overwitch
zsh: segmentation fault (core dumped) overwitch
which kills overwitch.
As per @dagargo's suggestion, I used gdb to track where the issue was coming from and below are those findings:
Reading symbols from /usr/local/bin/overwitch...
(gdb) run
Starting program: /usr/local/bin/overwitch
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff4bff640 (LWP 99373)]
[New Thread 0x7fffeffff640 (LWP 99374)]
[New Thread 0x7fffef7fe640 (LWP 99375)]
[Thread 0x7fffef7fe640 (LWP 99375) exited]
[New Thread 0x7fffef7fe640 (LWP 99376)]
[New Thread 0x7fffeeffd640 (LWP 99377)]
[Thread 0x7fffef7fe640 (LWP 99376) exited]
[New Thread 0x7fffef7fe640 (LWP 99378)]
[New Thread 0x7fffee7fc640 (LWP 99379)]
[Thread 0x7fffeeffd640 (LWP 99377) exited]
[Thread 0x7fffef7fe640 (LWP 99378) exited]
[Thread 0x7fffee7fc640 (LWP 99379) exited]
[New Thread 0x7fffee7fc640 (LWP 99380)]
[New Thread 0x7fffef7fe640 (LWP 99381)]
[New Thread 0x7fffeeffd640 (LWP 99382)]
[New Thread 0x7fffedf29640 (LWP 99384)]
[New Thread 0x7fffd61ff640 (LWP 99385)]
[Thread 0x7fffd61ff640 (LWP 99385) exited]
[New Thread 0x7fffd59fe640 (LWP 99387)]
[New Thread 0x7fffd61ff640 (LWP 99386)]
[Thread 0x7fffd59fe640 (LWP 99387) exited]
[Thread 0x7fffd61ff640 (LWP 99386) exited]
[New Thread 0x7fffd61ff640 (LWP 99388)]
[Thread 0x7fffd61ff640 (LWP 99388) exited]
[Thread 0x7fffedf29640 (LWP 99384) exited]
[New Thread 0x7fffedf29640 (LWP 99389)]
[Thread 0x7fffedf29640 (LWP 99389) exited]
[New Thread 0x7fffedf29640 (LWP 99391)]
[Thread 0x7fffeeffd640 (LWP 99382) exited]
[Thread 0x7fffee7fc640 (LWP 99380) exited]
[New Thread 0x7fffee7fc640 (LWP 99392)]
[New Thread 0x7fffeeffd640 (LWP 99393)]
[Thread 0x7fffeeffd640 (LWP 99393) exited]
[New Thread 0x7fffeeffd640 (LWP 99394)]
[New Thread 0x7fffd61ff640 (LWP 99395)]
[New Thread 0x7fffd59fe640 (LWP 99396)]
[New Thread 0x7fffd51fd640 (LWP 99397)]
[Thread 0x7fffef7fe640 (LWP 99381) exited]
Thread 24 "overwitch" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd51fd640 (LWP 99397)]
0x000055555555b702 in jclient_copy_o2j_audio (desc=0x55555565a4b0, buffer=0x7fffd51fc520, nframes=512, f=0x7fffd8034224) at jclient.c:283
283 buffer[j][i] = *f;
edit: just to followup, i tried changing back and forth from main to fx outputs and overwitch wouldn't die immediately, but eventually (3-5th time?) it would die w/ the segmentation fault (core dumped) error; hope this helps.
I've tried to replicate this without success.
It works well for me with Ardour 7 and Bitwig 5 (just installed from the flatpak with the 30 days evaluation license) . Everything on Debian bookworm (stable) running the included version of PipeWire and Ardour. The kernel is the RT version shipped with Debian.
$ uname -a
Linux asuka 6.1.0-9-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux
What Bitwig and PipeWire versions are you running?
You were testing this over the master branch with your patch, right?
Since the Debian 12 release (last month) I have not worked much with audio until now. I've been doing some testing and I've noticed that included version of PipeWire (0.3.65) was having some xruns when making connections besides having some timing issues (accurate timing is needed by Overwitch resampler to work smoothly).
I've upgraded it to the Debian testing version (0.3.76) which works much better.
What version of PipeWire are you running?
$ pipewire --version
pipewire
Compiled with libpipewire 0.3.76
Linked with libpipewire 0.3.76
hey, was just about to respond.
❯ pipewire --version
pipewire
Compiled with libpipewire 0.3.74
Linked with libpipewire 0.3.74
❯ uname -a
Linux t14s 6.4.6-76060406-generic #202307241739~1690928105~22.04~d567a38 SMP PREEMPT_DYNAMIC Tue A x86_64 x86_64 x86_64 GNU/Linux
5.0.4 of bitwig
You were testing this over the master branch with your patch, right?
and yes, that's correct. i also opened an issue for the pop!_os folks to bump pipewire. once that's merged, i'll test again. at the moment though, it's not really an issue for me.
I had this issue too occasionally and I suspected that there was something going on at the PipeWire level when making connections. It looks like it could be caused by this issue, which has been solved in the last release (0.3.80).
At least, I has not crashed for me yet.
Let me know if upgrading PipeWire fixes the issue for you.
looks like it's still waiting to be merged for pop!_os: https://github.com/pop-os/pipewire/pulls
i'll test when that's been merged, and will also, finally 🙂, look into making a PR for AHfx+ for https://github.com/dagargo/elektroid
Has the issue been solved with the last PipeWire versión?
it was just merged for pop!_os, so i'll give it a go soon to see if the same issue occurs.
looks like that no longer happens, though when changing driver models i got the following:
❯ overwitch
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
corrupted double-linked list
zsh: IOT instruction (core dumped) overwitch
❯ overwitch
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 256.025046 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 256.025046 (output 0, expected 48)
...
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 388.594439 (output 0, expected 48)
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274756.168789 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274796.806406 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274837.414546 (output 0, expected 48)
^CERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274877.993207 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274918.542389 (output 0, expected 48)What do you mean with "driver models"?
Perhaps it's something new in PipeWire that needs to be addressed as ratios as higher as 4 or as lower as 0.25 are very likely an error.
The ratios are the measured sampling rate of an Overbridge device / sampling rate of the host audio interface.
ah, sorry about that i meant where you choose the audio drive in bitwig:
Definitely, Overwitch should handle this kind of changes and restart the internal resamplers.
I'll try to find a way to detect those.
While definitely there are issues with the latency due to the timing changes when restarting the audio system, I see no crashes and the ratios are similar.
Are you using the Overwitch master branch?
In my setup, the JACK audio model seems to work better. No idea about the differences with the PipeWire one as the later is a replacement for the former and should be the same server.
However...
I think I might have come up with a solution to to both this issue and #52.
It's possible for a client to be notified when another client it registered or unregistered. When that happens, the resampler can be restarted. I've chosen to restart the resampler only when clients are unregistered.
Keep in mind that a restart implies an audio pause.
You can already try this change from the master branch. Let me know if this improves anything for you.
doh, i wasn't using the latest. will give'r another spin and keep ya posted.
seems all good here w/ latest and 0.3.82 of pipewire.
cheers 🍻