17 Jan
2012
17 Jan
'12
10:21 p.m.
On Tue, 17 Jan 2012 23:03:29 +0100
Robin Gareus <robin(a)gareus.org> wrote:
On 01/17/2012 10:27 PM, Renato wrote:
thanks Robin, hopefully tomorrow I'll have some time to try these
things.
BTW the crash has to do with creating feedback lines in ams... I even
tried inserting a delay in the feedback line (suggestion I found in a
youtube comment so that says it all ;) but it seemed reasonable) but
still this sort of thing seems to make ams extremely unstable.
best wishes,
renato
Hi, I'm getting a consistent crash in ams
I'd like to report, but
for it to be useful I think I have to provide a backtrace, right?
How do I compile ams to get that? I don't see any "debug" option or
similar in ./configure --help...
Hi Renato,
You need to compile the program with gcc's '-g' option in order to
produce useful backtraces. Some software has this flag turned on by
default (check the output of `make`) but duplicating it does not hurt.
With most autotools' configured projects you can that with environment
variables:
CFLAGS=-g CXXFLAGS=-g ./configure
(Custom configure scripts often accept '--with-cflags=-g' or similar
options - usually documented in ./INSTALL)
Next run the program under the GNU debugger:
gdb --args ./path/to/binary [options]
## inside gdb:
run
## wait until it crashes, then type
thread apply all bt
## and send the output upstream.
gdb slows things down. If the application-under-test is a jack-client:
It may cause jack-timeouts and eventually jackd may kick out the
client (You should not be running jackd with realtime privileges at
the same time as jack-client under gdb). An Alternative to running
the program inside the debugger is to create core-dump of the crash,
and later analyze the dump with gdb:
ulimit -c unlimited
./my/bad/program
## crash
ls -l core.XXXXX
gdb ./my/bad/program core.XXXXX
thread apply all bt
HTH,
robin