chuck/libsndfile crash on linux (using libsndfile 1.0.11-1)
Hello (and thanks for chuck!), I'm having problems with chuck and libsndfile on linux (FC4, 2.6.14-0.10.rrt.rhfc4.ccrma, libsndfile version 1.0.11-1.rhfc4.ccrma). It crashes 90% of the time when trying to the load the example data files in the "otk_0x.ck" series with the following message: User defined signal 2. In src/util_sndfile.h, it looks like it's expecting version 1.0.10. So, that could certainly be the problem: ... #define PACKAGE "libsndfile" #define PACKAGE_BUGREPORT "erikd@mega-nerd.com" #define PACKAGE_NAME "libsndfile" #define PACKAGE_STRING "libsndfile 1.0.10" #define PACKAGE_TARNAME "libsndfile" #define PACKAGE_VERSION "1.0.10" ... I haven't tried installing 1.0.10 yet (its not in my distribution), but I tried upgrading to the latest FC4 version (1.0.11.3) with no luck. -scott BTW-- Here's the stack trace in debug-mode: ----------------------------------------------------------------------------------------------------------------------- (gdb) run /home/jsdavids/chuck/examples/otf_04.ck /home/jsdavids/chuck/examples/otf_03.ck /home/jsdavids/chuck/examples/otf_02.ck Starting program: /home/jsdavids/Desktop/new_installs/chuck-1.2.0.5/src/chuck /home/jsdavids/chuck/examples/otf_04.ck /home/jsdavids/chuck/examples/otf_03.ck /home/jsdavids/chuck/examples/otf_02.ck Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 [Thread debugging using libthread_db enabled] [New Thread -1208961344 (LWP 5945)] [New Thread -1208964176 (LWP 5946)] [New Thread -1217487952 (LWP 5947)] [New Thread -1225880656 (LWP 5948)] Program received signal SIGUSR2, User defined signal 2. [Switching to Thread -1225880656 (LWP 5948)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x48b454bb in __read_nocancel () from /lib/libc.so.6 #2 0xb7f17e69 in sf_open () from /usr/lib/libsndfile.so.1 #3 0xb7f1604e in sf_open () from /usr/lib/libsndfile.so.1 #4 0xb7f1656b in sf_open () from /usr/lib/libsndfile.so.1 #5 0xb7f140c6 in sf_command () from /usr/lib/libsndfile.so.1 #6 0xb7f151af in sf_open () from /usr/lib/libsndfile.so.1 #7 0x0811982d in sndbuf_ctrl_read (SELF=0x8385b00, ARGS=0x835860c, RETURN=0xb6ee72d4) at ugen_xxx.cpp:1939 #8 0x0805fe5b in Chuck_Instr_Func_Call_Member::execute (this=0x8358090, vm=0x82174b8, shred=0x8358210) at chuck_instr.cpp:2192 #9 0x08059002 in Chuck_VM::compute (this=0x82174b8) at chuck_vm.cpp:1416 #10 0x080590cf in Chuck_VM::run (this=0x82174b8, num_samps=256) at chuck_vm.cpp:650 #11 0x080ba157 in Digitalio::cb2 (buffer=0x83295a0 "", buffer_size=256, user_data=0x82174b8) at digiio_rtaudio.cpp:635 #12 0x080ca54f in RtApiJack::callbackEvent (this=0x830b180, nframes=256) at rtaudio.cpp:3325 #13 0x080ca698 in jackCallbackHandler (nframes=256, infoPointer=0x830b5f8) at rtaudio.cpp:2862 #14 0x4a594e01 in jack_client_close () from /usr/lib/libjack.so.0 #15 0xb6ee741b in ?? () #16 0x4a59b21b in ?? () from /usr/lib/libjack.so.0 #17 0x08328560 in ?? () #18 0x00000000 in ?? () (gdb) down Bottom (i.e., innermost) frame selected; you cannot go down. (gdb) up #1 0x48b454bb in __read_nocancel () from /lib/libc.so.6 (gdb) info frame Stack level 1, frame at 0xb6ee7040: eip = 0x48b454bb in __read_nocancel; saved eip 0xb7f17e69 called by frame at 0xb6ee7080, caller of frame at 0xb6ee7034 Arglist at 0xb6ee7034, args: Locals at 0xb6ee7034, Previous frame's sp is 0xb6ee7040 Saved registers: ebx at 0xb6ee7034, ebp at 0xb6ee7024, eip at 0xb6ee703c (gdb) up #2 0xb7f17e69 in sf_open () from /usr/lib/libsndfile.so.1 (gdb) info frame Stack level 2, frame at 0xb6ee7080: eip = 0xb7f17e69 in sf_open; saved eip 0xb7f1604e called by frame at 0xb6ee70c0, caller of frame at 0xb6ee7040 Arglist at 0xb6ee7078, args: Locals at 0xb6ee7078, Previous frame's sp is 0xb6ee7080 Saved registers: ebx at 0xb6ee706c, ebp at 0xb6ee7078, esi at 0xb6ee7070, edi at 0xb6ee7074, eip at 0xb6ee707c (gdb) frame #2 0xb7f17e69 in sf_open () from /usr/lib/libsndfile.so.1 (gdb) down #1 0x48b454bb in __read_nocancel () from /lib/libc.so.6 (gdb) down #0 0xffffe410 in __kernel_vsyscall () (gdb) info frame Stack level 0, frame at 0xb6ee7034: eip = 0xffffe410 in __kernel_vsyscall; saved eip 0x48b454bb called by frame at 0xb6ee7040 Arglist at 0xb6ee702c, args: Locals at 0xb6ee702c, Previous frame's sp is 0xb6ee7034 Saved registers: ebp at 0xb6ee7024, eip at 0xb6ee7030 -- Scott Davidson jsd_290@fastmail.fm -- http://www.fastmail.fm - I mean, what is it about a decent email service?
Hi Scott!
I'm having problems with chuck and libsndfile on linux (FC4, 2.6.14-0.10.rrt.rhfc4.ccrma, libsndfile version 1.0.11-1.rhfc4.ccrma). It crashes 90% of the time when trying to the load the example data files in the "otk_0x.ck" series with the following message: User defined signal 2.
Is anyone else experiencing similar problems? Are you building for alsa, jack, or oss?
In src/util_sndfile.h, it looks like it's expecting version 1.0.10. So, that could certainly be the problem:
Under linux, the default is to use libsndfile headers and libraries installed on your system (and completely ignore util_sndfile.*). So, it should be using 1.0.11-1.rhfc4.ccrma, unless you changed it in the makefile. Have you tested other apps that also links against this version of libsndfile? It's possible, but unlikely, that there is something weird with your libsndfile headers/libraries. It's more probable that chuck is doing something funny. Ge!
Hi Ge!
Is anyone else experiencing similar problems?
Are you building for alsa, jack, or oss?
I originally found the problem using jack, but it breaks the same way in alsa and oss. I haven't heard from anyone experiencing the same thing, so it might just be a problem with my machine. I did experience some file system corruption last weekend, so it's possible that was related, but other libsndfile clients work fine (sooperlooper and ardour, in particular).
Under linux, the default is to use libsndfile headers and libraries installed on your system (and completely ignore util_sndfile.*). So, it should be using 1.0.11-1.rhfc4.ccrma, unless you changed it in the makefile.
Nope, didn't change anything in the Makefile.
Have you tested other apps that also links against this version of libsndfile? It's possible, but unlikely, that there is something weird with your libsndfile headers/libraries. It's more probable that chuck is doing something funny.
Just sooperlooper and ardour, which work fine on the same files. I guess the next step would be to build a debug version of libsndfile, but unless anyone else is experiencing this, I'll probably wait until I have a clean slate and reinstall the OS for FC5 (sometime in the next month). Hopefully that'll fix it. I'll let you know if the problem persists. Let me know if you need anymore info, too, or if you need more debugging info (do you have any machines with ccrma/FC distros in the sound lab?) Thanks, -Scott -- Scott Davidson jsd_290@fastmail.fm -- http://www.fastmail.fm - Send your email first class
On Tue, Apr 18, 2006 at 07:18:33AM -0700, Scott Davidson wrote:
Under linux, the default is to use libsndfile headers and libraries installed on your system (and completely ignore util_sndfile.*). So, it should be using 1.0.11-1.rhfc4.ccrma, unless you changed it in the makefile.
Nope, didn't change anything in the Makefile.
You should make sure that when you compile ChucK, it is using your native libsndfile libraries. The ones included with ChucK currently break on Linux. Look for the lines: #FLAGS+= -D__CK_SDL_NATIVE__ #LIBS+= -lsdl And remove the #'s. martin robinson
Nope, didn't change anything in the Makefile.
You should make sure that when you compile ChucK, it is using your native libsndfile libraries. The ones included with ChucK currently break on Linux.
Look for the lines: #FLAGS+= -D__CK_SDL_NATIVE__ #LIBS+= -lsdl
And remove the #'s.
These lines were already uncommented. Bummer. Thanks anyways for the suggestion. I also tried commenting out the "SF_OBJ=util_sndfile.o" with no luck. I wonder if for some reason it is falling back on the libsndfile that comes with chuck, rather than my native lib. -Scott -- Scott Davidson jsd_290@fastmail.fm -- http://www.fastmail.fm - Email service worth paying for. Try it for free
On Wed, Apr 19, 2006 at 07:40:39AM -0700, Scott Davidson wrote:
Look for the lines: #FLAGS+= -D__CK_SDL_NATIVE__ #LIBS+= -lsdl These lines were already uncommented. Bummer. Thanks anyways for the
I'm sorry! You should look for the lines that say: #FLAGS+= -D__CK_SNDFILE_NATIVE__ #LIBS+= -lsndfile #SF_OBJ= martin robinson
i don't know if this is the right place to file a bug report, but i didn't find a better place. first there's a flaw in the OSC examples: instead of recv.event( "/foo/notes, i f" ) @=> OscEvent oe; it should be: recv.event( "/foo/notes", "i f" ) @=> OscEvent oe; secondly i can reproduce a crash of chuck while using OSC with reactivision (http://www.iua.upf.es/mtg/reactable/?software). if you uncomment the last comment below and then receive an osc-event chuck crashes. system: winXP, SP2, pentium M, 512MB hope this helps, chuck is great fun with reactivision... best joerg ---- crash script: sinosc si => JCRev r => dac; .1 => r.mix; OscRecv recv; 3333 => recv.port; recv.listen(); recv.event( "/tuio/2Dobj","s i i f f f f f f f f" ) @=> OscEvent oe; string str; int s; int i; float x; float y; // infinite event loop while ( true ) { // wait for event to arrive oe => now; // grab the next message from the queue. while ( oe.nextMsg() != 0 ) { oe.getString() @=> str; oe.getInt() => s; oe.getInt() => i; oe.getFloat() => x => si.gain; oe.getFloat() => y; y * 1000 => si.freq; <<< str, s, i, x, y >>>; // UNCOMMENT NEXT LINE TO CRASH CHUCK: //<<< oe.getString() >>>; } } -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
participants (4)
-
Ge Wang -
joerg piringer -
Martin Robinson -
Scott Davidson