[LAU] reporting a bug: getting a backtrace

[Renato]

On Tue, 17 Jan 2012 23:03:29 +0100
Robin Gareus <robin at gareus.org> wrote:

> On 01/17/2012 10:27 PM, Renato wrote:
> > 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

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