You are here

qjackctl-0.3.5 crash when jack running

qjackctl only works when jack is running. if it starts jack, jack runs and qjackctl immediately dies. if jack is already running it immediately dies.

I've --enabled-stacktrace and --enabled-debug, and ulimit -c unlimited, but I don't get any core dumps, nor a "segmentation fault" message.

This is running on debian testing, with a custom kernel 2.6.31.6-rt19, latest ALSA source downloaded/built (despite noticing afterward debian testing using same ver). Built also, sndfile, samplerate, and latest jack1...

Running in gdb gets the following output:


musys2@Scrapyard:~/SRC/qjackctl-0.3.5$ gdb qjackctl
GNU gdb (GDB) 7.0-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/musys2/SRC/qjackctl-0.3.5/qjackctl...done.
(gdb) run
Starting program: /home/musys2/SRC/qjackctl-0.3.5/qjackctl
[Thread debugging using libthread_db enabled]
Warning: no translation found for 'en_GB' locale: /usr/share/qt4/translations/qt_en_GB.qm
Warning: no translation found for 'en_GB' locale: /usr/local/share/locale/qjackctl_en_GB.qm
[New Thread 0x7ffff022c910 (LWP 21604)]
[New Thread 0x7fffef82b910 (LWP 21607)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef82b910 (LWP 21607)]
0x00007ffff7ffc634 in ?? ()
(gdb) thread apply all bt

Thread 3 (Thread 0x7fffef82b910 (LWP 21607)):
#0 0x00007ffff7ffc634 in ?? ()
#1 0x00007ffff7ffc7ed in gettimeofday ()
#2 0x00007ffff574402a in gettimeofday () at ../sysdeps/unix/sysv/linux/x86_64/gettimeofday.S:37
#3 0x00007ffff7bcd27c in jack_thread_wait () from /usr/local/lib64/libjack.so.0
#4 0x00007ffff7bcd41a in jack_client_thread () from /usr/local/lib64/libjack.so.0
#5 0x00007ffff745473a in start_thread (arg=) at pthread_create.c:300
#6 0x00007ffff578169d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7ffff022c910 (LWP 21604)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1 0x00007ffff7bce4ab in mb_thread_func () from /usr/local/lib64/libjack.so.0
#2 0x00007ffff745473a in start_thread (arg=) at pthread_create.c:300
#3 0x00007ffff578169d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fde750 (LWP 21601)):
#0 0x00007ffff5776743 in *__GI___poll (fds=, nfds=, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007ffff330490a in ?? () from /usr/lib/libxcb.so.1
#2 0x00007ffff330691c in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#3 0x00007ffff53ca0c4 in _XReply () from /usr/lib/libX11.so.6
#4 0x00007ffff53a7716 in XGetWindowProperty () from /usr/lib/libX11.so.6
#5 0x0000000000416b76 in qjackctlApplication::x11EventFilter (this=0x7fffffffe490, pEv=0x7fffffffdcc0) at src/main.cpp:203
#6 0x00007ffff682d39f in qt_x11EventFilter (ev=0x7fffffffdcc0) at kernel/qapplication_x11.cpp:377
#7 0x00007ffff68404c1 in QApplication::x11ProcessEvent (this=0x7fffffffe490, event=0x7fffffffdcc0) at kernel/qapplication_x11.cpp:3273
#8 0x00007ffff686976c in x11EventSourceDispatch (s=0x72e910, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146
#9 0x00007ffff3da113a in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00007ffff3da4998 in ?? () from /lib/libglib-2.0.so.0
#11 0x00007ffff3da4b4c in g_main_context_iteration () from /lib/libglib-2.0.so.0
#12 0x00007ffff632c39c in QEventDispatcherGlib::processEvents (this=0x72ac70, flags=) at kernel/qeventdispatcher_glib.cpp:407
#13 0x00007ffff6868f1f in QGuiEventDispatcherGlib::processEvents (this=0x7fffffffc1f0, flags=) at kernel/qguieventdispatcher_glib.cpp:202
#14 0x00007ffff6302562 in QEventLoop::processEvents (this=, flags=...) at kernel/qeventloop.cpp:149
#15 0x00007ffff6302934 in QEventLoop::exec (this=0x7fffffffdff0, flags=...) at kernel/qeventloop.cpp:201
#16 0x00007ffff6304ba4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#17 0x0000000000416482 in main (argc=1, argv=0x7fffffffe708) at src/main.cpp:396
Current language: auto
The current source language is "auto; currently asm".
Current language: auto
The current source language is "auto; currently c".
(gdb) quit
A debugging session is active.

Inferior 1 [process 21601] will be killed.

Forums: 
rncbc's picture

As it seems you have jack1 built from source and installed in /usr/local. Is it possible you have a previous libjack installation under eg. /usr ?? That might be a concern, as it reads from the stack trace above, qjackctl is dying due on a segfault inside jack client thread, which may infer some linkage mismatch (jackd and qjackctl linked to different libjack instances).

Make sure you uninstall any pre-packaged jack, before you build and install jack from source again. BTW, which version of jack1 ?

HTH

No, there is no possibility of a jack conflict, I have not installed any audio packages. Jack version is 0.118.0.

rncbc's picture

Can you try with qjackctl svn trunk, if things are any better?

Hi Rui,

I've identified the problem. Sorry, it was my fault - I built jack with --enable-preemption-check.

Thanks.

rncbc's picture

Indeed, that configure option isn't of no good use anymore, I think. It was once used for signaling jackd that its real-time scheduled code-path is being preempted, which should never ever happen in normal and controlled conditions. It was also only applicable with the PREEMPT_RT patch of the time (more than 2years ago?) and I guess it's not that useful anymore. Anyway, it was instrumental for jackd development, not a good thing for users to try;)

Glad you noticed it.

Cheers

Add new comment