17 Jan
2012
17 Jan
'12
10:29 p.m.
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...
best wishes,
renato
17 Jan
17 Jan
11:03 p.m.
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
11: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 
21 Jan
21 Jan
1:11 a.m.
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(a)gmail.com
On 17 January 2012 22:19, Renato <rennabh(a)gmail.com> wrote:
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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 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 
1:30 a.m.
On Sat, Jan 21, 2012 at 12:11:10AM +0000, Alan Russell wrote:
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.
Indeed it does, with a segfault.
Creating loops is explicitly allowed in AMS, and it
used to 'just work'. I'll have look as soon as the
LAC paper is finished :-)
Pretty annoying, as feedback loops are supposed to be
a major feature
of modular synths.
They are. But you'll have one period of delay, so
it's not exactly the same as on an analog synth.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
11:44 a.m.
On Sat, Jan 21, 2012 at 12:11:10AM +0000, Alan Russell wrote:
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.
In module.cpp change
float **Module::getData(int index)
{
if (!cycleReady) {
generateCycle();
cycleReady = true;
}
return data[index];
}
to
float **Module::getData(int index)
{
if (!cycleReady) {
cycleReady = true;
generateCycle();
}
return data[index];
}
and recompile. If you have recent compilation tools you may
have to add -ldl to the list of libraries in Makefile.
The order of these two statements was apparently changed,
but it *does* matter. If there is a loop, getData() for one
particular module will call itself before generateCycle()
returns. If that happens generateCycle() must not be called
again.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
4:50 p.m.
Am Tue, 17. Jan 2012 um 23:19:18 +0100 schrieb Renato:
Hi Renato,
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.
you should go for a fresh cvs checkout of ams to get rid of this and
some other bugs.
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
22 Jan
22 Jan
10:10 a.m.
On Sat, 21 Jan 2012 16:50:35 +0100
Guido Scholz <guido.scholz(a)bayernline.de> wrote:
Am Tue, 17. Jan 2012 um 23:19:18 +0100 schrieb
Renato:
Hi Renato,
Hi, yes it works! feedback loops are fun :)
any hope of having a look at that JACK Transport seq24 bug now ? ;)
cheers,
renato
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.
you should go for a fresh cvs checkout of ams to get rid of this and
some other bugs.
Guido
4506
days inactive
4511
days old
linux-audio-user@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Alan Russell -
Fons Adriaensen -
Guido Scholz -
Renato -
Robin Gareus