Thanks for the syntax, Ben. I've never use gdb before.

The output was:

(gdb) bt #0 0x080af12a in sys_setchsr (chin=270238624, chout=1323783775, sr=44100) at s_audio.c:152 #1 0x080b0553 in sys_open_audio (naudioindev=2, audioindev=0xbf9ca7a4, nchindev=2, chindev=0xbf9ca794, naudiooutdev=2, audiooutdev=0xbf9ca784, nchoutdev=2, choutdev=0xbf9ca774, rate=44100, advance=50, enable=0) at s_audio.c:308 #2 0x080a73ec in sys_main (argc=1, argv=0xbf9ca864) at s_main.c:947 #3 0x4ee26d5f in __libc_start_main () from /lib/libc.so.6 #4 0x08054ccd in _start ()

Any idea how to make sense of this?

cheers, David __ _ _ _ _ __ ___ _ _ __ _ ___ ____ _ __ __ __ _ __ __ To talk about it is to miss the point http://sintheta.org

B. Bogart wrote:

% gdb pd (gdb) run [pd args here] stuff... (gdb) bt

Should do it.

David NG McCallum wrote:

...

Hello list,

I recently got back to working with Pd on my laptop after a long hiatus. I compiled 39.2 and Pd segfaults with no other messages other than "Segmentation fault". I tried running older versions and got the same error.

I'm on FC4. I'd previously used a planet CCRMA kernel, switched back to the main FC4 kernel, and now just switched back to CCRMA, if that affects anything.

"-verbose" doesn't give any more information either.

Any ideas on how to figure this out?

Thanks! David

Awesome, it works!

Any idea why it might be making these assumptions about the number of channels?

D __ _ _ _ _ __ ___ _ _ __ _ ___ ____ _ __ __ __ _ __ __ To talk about it is to miss the point http://sintheta.org

Martin Peach wrote:

David NG McCallum wrote:

...

Thanks for the syntax, Ben. I've never use gdb before.

The output was:

(gdb) bt #0 0x080af12a in sys_setchsr (chin=270238624, chout=1323783775, sr=44100) at s_audio.c:152 #1 0x080b0553 in sys_open_audio (naudioindev=2, audioindev=0xbf9ca7a4, nchindev=2, chindev=0xbf9ca794, naudiooutdev=2, audiooutdev=0xbf9ca784, nchoutdev=2, choutdev=0xbf9ca774, rate=44100, advance=50, enable=0) at s_audio.c:308 #2 0x080a73ec in sys_main (argc=1, argv=0xbf9ca864) at s_main.c:947 #3 0x4ee26d5f in __libc_start_main () from /lib/libc.so.6 #4 0x08054ccd in _start ()

Any idea how to make sense of this?

Back-tracing the stack shows that it crashed in a function named sys_setchsr which, if you look in the source code file s_audio.c, allocates memory for sound buffers. There is no checking done to see if the pointers returned by malloc are valid (non-NULL) or that the sizes requested are valid (chin*DEFDACBLKSIZE*sizeof(float)) = 270238624*64*8, so probably that's why it crashed: you're asking for a huge amount of ram. Somehow pd thinks you have a _lot_ of sound channels. Maybe you could try using the command-line arguments -inchannels and -outchannels to set just 2 channels. Or maybe you should use alsa or oss or something else for audio...just guessing.

Martin

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Mon, 16 Jan 2006, David NG McCallum wrote:

Any idea why it might be making these assumptions about the number of channels?

Instead of gdb, try valgrind. It's a different kind of debugger. It's not interactive like gdb, but you can make it report many things that gdb can't.

For example, I think that valgrind would report that the number of channels was lifted from some uninitialized variable and would bitch about it. I would guess that a use of ioctl() failed and Pd didn't realise it.

Did you say which sound card interface you use with Pd? Because your backtrace doesn't mention any of them (s_audio_oss, s_audio_alsa, s_audio_jack, etc)

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada