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@xxxxxxxxx On 17 January 2012 22:19, Renato <rennabh@xxxxxxxxx> wrote: > On Tue, 17 Jan 2012 23:03:29 +0100 > Robin Gareus <robin@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
