Re: [Jack-Devel] gdb-ing jack apps?

PrevNext  Index
DateSun, 24 Apr 2011 12:05:28 +0100
From James Morris <[hidden] at gmail dot com>
ToDan Muresan <[hidden] at gmail dot com>
Cc[hidden] at jackaudio dot org
In-Reply-ToDan Muresan [Jack-Devel] gdb-ing jack apps?
Follow-UpDan Muresan Re: [Jack-Devel] gdb-ing jack apps?
On 24 April 2011 08:25, Dan Muresan <[hidden]> wrote:
> Hi,
>
> I've been unable to debug my jack app in gdb. Take the auto-server
> case. Whenever gdb stops the program due to a signal (either ^C or a
> segfault) an endless stream of
>
> subgraph starting at <client> timed out (subgraph_wait_fd=14, status =
> 0, state = Triggered, pollret = 0 revents = 0x0)
>
> gets printed, and I have to kill gdb from another shell.
>
> If I start the server from qjackctl, the same process crashes qjackctl.
>
> I've tried exiting the process thread on lost frames, but it doesn't help.
>
> I've seen reports of jackd and gdb on the net, so there has to be a
> way. What could be the problem? I am of course not expecting to stop a
> jack app and then continue, but at least I want to be able to see
> backtraces, inspect variables etc in gdb.

One way is to get core dumps from the app (ulimit -c unlimited) and
then gdb ./myapp core, and then in gdb: thread apply all bt.

You can also use the dummy driver (instead of, for example Alsa) with
a long --timeout value to be able to step through the code.

James.
PrevNext  Index

1303643149.30680_0.ltw:2,a <BANLkTiku3q=HehFGT4w9r3gTjZ+HL=LDSA at mail dot gmail dot com>