Hi all, I tried to run chuck (cvs from just an hour ago) in --loop mode. I can then add shreds, but if I try to remove one, chuck crashes: chuck --srate44100 --loop [chuck](VM): sporking incoming shred: 1... [chuck](VM): sporking incoming shred: 2... Segmentation fault the commands leading to this were: nick@detritus ~/build/chuck_dev/examples $ chuck + moe.ck nick@detritus ~/build/chuck_dev/examples $ chuck + larry.ck nick@detritus ~/build/chuck_dev/examples $ chuck - 2 (gdb) r --srate44100 --loop Starting program: /usr/bin/chuck --srate44100 --loop warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIG32, Real-time event 32. 0x0fc292f4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x0fc292f4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) c Continuing. [chuck](VM): sporking incoming shred: 1... [chuck](VM): sporking incoming shred: 2... Program received signal SIGSEGV, Segmentation fault. 0x0fef277c in mallopt () from /lib/libc.so.6 (gdb) bt #0 0x0fef277c in mallopt () from /lib/libc.so.6 #1 0x0ffbc5ec in ?? () from /lib/libc.so.6 (gdb) hmmm, is there a double call to free() going on or anything similar? (Oh, and gentoo on Powerbook Aluminium) Cheers, Niklas -- Computer Music PhD-student University of Waikato Hamilton New Zealand
Hi Niklas! Hmm... I tried this on os x and couldn't seg fault. Did you do a clean build? does it happen consistently? it is suspicious that GDB points to getconcurrency()... shreds do not use pthreads (obviously, ha). it could be a synchronization bug in the server code and the VM. Ge! On Jul 26, 2004, at 7:56 PM, Niklas Werner wrote:
Hi all,
I tried to run chuck (cvs from just an hour ago) in --loop mode. I can then add shreds, but if I try to remove one, chuck crashes:
chuck --srate44100 --loop [chuck](VM): sporking incoming shred: 1... [chuck](VM): sporking incoming shred: 2... Segmentation fault
the commands leading to this were:
nick@detritus ~/build/chuck_dev/examples $ chuck + moe.ck nick@detritus ~/build/chuck_dev/examples $ chuck + larry.ck nick@detritus ~/build/chuck_dev/examples $ chuck - 2
(gdb) r --srate44100 --loop Starting program: /usr/bin/chuck --srate44100 --loop warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code.
Program received signal SIG32, Real-time event 32. 0x0fc292f4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) c Continuing.
Program received signal SIG32, Real-time event 32. 0x0fc292f4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) c Continuing. [chuck](VM): sporking incoming shred: 1... [chuck](VM): sporking incoming shred: 2...
Program received signal SIGSEGV, Segmentation fault. 0x0fef277c in mallopt () from /lib/libc.so.6 (gdb) bt #0 0x0fef277c in mallopt () from /lib/libc.so.6 #1 0x0ffbc5ec in ?? () from /lib/libc.so.6 (gdb)
hmmm, is there a double call to free() going on or anything similar?
(Oh, and gentoo on Powerbook Aluminium)
Cheers,
Niklas -- Computer Music PhD-student University of Waikato Hamilton New Zealand _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
On Tue, 27 Jul 2004 12:31, Ge Wang wrote:
Hi Niklas!
Hmm... I tried this on os x and couldn't seg fault. Did you do a clean build? does it happen consistently? yes and yes. Any other Linux users out there?
it is suspicious that GDB points to getconcurrency()... shreds do not use pthreads (obviously, ha). Hmm, correct, but those first pthread things are more likely alsa/sound-related, and they are only SIG32, (other programs run in gdb receive the same signals, but run fine afterwards) it could be a synchronization bug in the server code and the VM. so? What can we do?
Cheers, Niklas -- Computer Music PhD-student University of Waikato Hamilton New Zealand
the same here # ../chuck --srate44100 --loop [chuck](VM): sporking incoming shred: 1... Segmentation fault after ../chuck + moe.ck i'm on linux 2.6.7 with alsa did anyone test it with 2.4 kernel? (i praised chuck too early... :-)) Niklas Werner wrote:
On Tue, 27 Jul 2004 12:31, Ge Wang wrote:
Hi Niklas!
Hmm... I tried this on os x and couldn't seg fault. Did you do a clean build? does it happen consistently?
yes and yes. Any other Linux users out there?
it is suspicious that GDB points to getconcurrency()... shreds do not use pthreads (obviously, ha).
Hmm, correct, but those first pthread things are more likely alsa/sound-related, and they are only SIG32, (other programs run in gdb receive the same signals, but run fine afterwards)
it could be a synchronization bug in the server code and the VM.
so? What can we do?
I think this is related to the earlier gain paramater crash. it suggested there was a compiler gcc bug in the -O3 or that chuck may be trashing memory. try:
take out the -O3 flag in the make file make clean make linux-alsa
please also post your gcc version (gcc --version). Best, Ge! On Jul 27, 2004, at 5:32 AM, smoerk wrote:
the same here
# ../chuck --srate44100 --loop [chuck](VM): sporking incoming shred: 1... Segmentation fault
after ../chuck + moe.ck
i'm on linux 2.6.7 with alsa
did anyone test it with 2.4 kernel?
(i praised chuck too early... :-))
Niklas Werner wrote:
On Tue, 27 Jul 2004 12:31, Ge Wang wrote:
Hi Niklas!
Hmm... I tried this on os x and couldn't seg fault. Did you do a clean build? does it happen consistently? yes and yes. Any other Linux users out there? it is suspicious that GDB points to getconcurrency()... shreds do not use pthreads (obviously, ha). Hmm, correct, but those first pthread things are more likely alsa/sound-related, and they are only SIG32, (other programs run in gdb receive the same signals, but run fine afterwards) it could be a synchronization bug in the server code and the VM. so? What can we do?
_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
On Wed, 28 Jul 2004 10:57, Ge Wang wrote:
I think this is related to the earlier gain paramater crash. it suggested there was a compiler gcc bug in the -O3 or that chuck may be trashing memory.
try:
take out the -O3 flag in the make file
OK, some of the optimisations in -O2 are the culprits... -O1 works... choose freely: -O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags: -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops -falign-labels -fcrossjumping
make clean make linux-alsa
please also post your gcc version (gcc --version). gcc (GCC) 3.4.1 (Gentoo Linux 3.4.1-r1, ssp-3.4-2, pie-8.7.6.3)
Cheers, Niklas -- Computer Music PhD-student University of Waikato Hamilton New Zealand
it's the same with gcc 3.3.4. I have segfaults with -O2 and -O3, but it works with -O1. Niklas Werner wrote:
On Wed, 28 Jul 2004 10:57, Ge Wang wrote:
I think this is related to the earlier gain paramater crash. it suggested there was a compiler gcc bug in the -O3 or that chuck may be trashing memory.
try:
take out the -O3 flag in the make file
OK, some of the optimisations in -O2 are the culprits... -O1 works...
choose freely:
-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags: -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops -falign-labels -fcrossjumping
make clean make linux-alsa
please also post your gcc version (gcc --version).
gcc (GCC) 3.4.1 (Gentoo Linux 3.4.1-r1, ssp-3.4-2, pie-8.7.6.3)
Cheers,
Niklas -- Computer Music PhD-student University of Waikato Hamilton New Zealand _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got the same results, working with -01 but not -02 or -03, for the gain ugen segfault reported earlier. I'm using gcc 3.3.3 matt smoerk wrote: | it's the same with gcc 3.3.4. I have segfaults with -O2 and -O3, but it | works with -O1. | | Niklas Werner wrote: | |> On Wed, 28 Jul 2004 10:57, Ge Wang wrote: |> |>> I think this is related to the earlier gain paramater crash. |>> it suggested there was a compiler gcc bug in the -O3 or |>> that chuck may be trashing memory. |>> |>> try: |>> > take out the -O3 flag in the make file |> |> |> |> OK, some of the optimisations in -O2 are the culprits... -O1 works... |> |> choose freely: |> |> -O2 turns on all optimization flags specified by -O. It also turns on |> the following optimization flags: -fforce-mem -foptimize-sibling-calls |> -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks |> -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm |> -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations |> -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock |> -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks |> -freorder-functions -fstrict-aliasing -funit-at-a-time |> -falign-functions -falign-jumps -falign-loops -falign-labels |> -fcrossjumping |> |> |>> > make clean |>> > make linux-alsa |>> |>> please also post your gcc version (gcc --version). |> |> |> gcc (GCC) 3.4.1 (Gentoo Linux 3.4.1-r1, ssp-3.4-2, pie-8.7.6.3) |> |> Cheers, |> |> Niklas |> -- |> Computer Music PhD-student |> University of Waikato |> Hamilton |> New Zealand |> _______________________________________________ |> chuck-dev mailing list |> chuck-dev@lists.cs.princeton.edu |> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev |> | | _______________________________________________ | chuck-dev mailing list | chuck-dev@lists.cs.princeton.edu | https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev | . | - -- Matthew Shanley E-mail: mshanley@alum.rpi.edu GnuPG Public Key ID : 0x5D3C2489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBCPJg2B97+F08JIkRAv6tAJ9F1MPvC7gl8PJgR2WnoJFIiCNRxQCfZk8u XWRwYhkuHOhLe5/nHm5dAOI= =2HLn -----END PGP SIGNATURE-----
participants (4)
-
Ge Wang -
Matthew Shanley -
Niklas Werner -
smoerk