Re: [LAU] reporting a bug: getting a backtrace

I got the same bug trying to patch a feedback loop on mine. It doesn't
seem to matter what modules are in the feedback line, even a gain
object set to 0 (-infinity dB, whatever). As soon as you close the
loop, the program exits.

Pretty annoying, as feedback loops are supposed to be a major feature
of modular synths.

Alan Russell
ajrussellaudio@email-addr-hidden

On 17 January 2012 22:19, Renato <rennabh@email-addr-hidden> wrote:
> On Tue, 17 Jan 2012 23:03:29 +0100
> Robin Gareus <robin@email-addr-hidden> 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
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Jan 21 04:15:02 2012