[LAU] Segfault using zita-j2a

[Robin Gareus]

On 10/25/2012 04:54 PM, Jannis Achstetter wrote:
> Hi Fons, hi list,
> 
> I've been trying to get zita-a2jbridge working on my laptop. JACK is
> running with the internal Intel HDA-card via ALSA backend.
> Using the Edirol UA-101 as JACK's main-backend works w/o problems and
> using alsa_out & alsa_in works, too.
> Software versions I am using:
> media-libs/zita-alsa-pcmi-0.2.0
> media-libs/zita-resampler-1.2.0
> media-sound/zita-ajbridge-0.2.2
> media-sound/jack-audio-connection-kit-1.9.8
> 
> Here's the output of gdb trying to run zita-j2a:
> kripton at miramis ~ $ cat /proc/asound/cards
>  0 [Intel          ]: HDA-Intel - HDA Intel
>                       HDA Intel at 0xfc020000 irq 46
>  1 [Loopback       ]: Loopback - Loopback
>                       Loopback 1
>  2 [UA101          ]: UA-101 - UA-101
>                       EDIROL UA-101 (serial ZT40539), 48000 Hz at
> usb-0000:00:1d.7-2, high speed
> 29 [ThinkPadEC     ]: ThinkPad EC - ThinkPad Console Audio Control
>                       ThinkPad Console Audio Control at EC reg 0x30, fw
> 7VHT16WW-1.06
> kripton at miramis ~ $ gdb zita-j2a
> GNU gdb (Gentoo 7.5 p1) 7.5
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.gentoo.org/>...
> Reading symbols from /usr/bin/zita-j2a...done.
> (gdb) r -j UA101 -d hw:UA101 -c 10 -v
> Starting program: /usr/bin/zita-j2a -j UA101 -d hw:UA101 -c 10 -v
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> playback :
>   nchan  : 10
>   fsamp  : 48000
>   fsize  : 256
>   nfrag  : 2
>   format : S32_LE
> capture  : not enabled
> [New Thread 0x7ffff7f9f700 (LWP 15169)]
> [New Thread 0x7ffff7f1e700 (LWP 15170)]
> [New Thread 0x7ffff7e9d700 (LWP 15171)]
> [New Thread 0x7ffff7fce700 (LWP 15172)]
> Starting synchronisation.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7e9d700 (LWP 15171)]
> 0x00007ffff7bd8760 in VResampler::process (this=0x6265a0) at
> vresampler.cc:217
> 217     vresampler.cc: No such file or directory.
> (gdb) bt
> #0  0x00007ffff7bd8760 in VResampler::process (this=0x6265a0) at
> vresampler.cc:217
> #1  0x0000000000403951 in Jackclient::playback (this=0x6262d0,
> nframes=128) at jackclient.cc:222
> #2  0x00000000004042eb in Jackclient::jack_process (this=0x6262d0,
> nframes=128) at jackclient.cc:467
> #3  0x00007ffff779c61a in ?? () from /usr/lib64/libjack.so.0
> #4  0x00007ffff77af760 in ?? () from /usr/lib64/libjack.so.0
> #5  0x00007ffff7575ec6 in start_thread () from /lib64/libpthread.so.0
> #6  0x00007ffff6aa08ad in clone () from /lib64/libc.so.6
> (gdb) q
> A debugging session is active.
> 
>         Inferior 1 [process 15160] will be killed.
> 
> Quit anyway? (y or n) y
> 
> Any ideas?
>
Classic race condition. The jack_client is activated before the
resampler is initialized.

zita-j2a.cc:200 creates the jack-client and calls jack_activate.
process_callbacks can arrive starting now.

but not until zita-j2a.cc:211 calls J->start() the data-structures
required to do the processing are initialized.

Easiest solution is probably to check if start() has been called in the
process callback:

--- a/jackclient.cc
+++ b/jackclient.cc
@@ -301,6 +301,8 @@ int Jackclient::jack_process (int nframes)
     jack_nframes_t  ft;
     double          tj, err, d1, d2;

+    if (_state == INIT) return 0;
+
     // Buffer size change or other evil.
     if (_state == TERM)