Dear PureData developer list,
I have recently switched from Max/MSP to PureData as I like the fact that it runs on linux and also like that it is open source. I am using it for a big project in order to analyze audio using the aubio plugin, and then based on the analysis output open sound control packets using packOSC and sendUDP to a locally running server which will control a large number of LED lights.
The program I am using to analyze the music and output control signals is pretty basic, but for some reason after running for an hour or two, PureData inexplicibly segfaults without any debug messages even at pdextended -d 10. I assume at that point any debug messages that are being generated are being printed, so something is happening for which there is no debugging handler to explain the problem.
I have attached the offending script. It is running on ubuntu 10.04 using the PD repository for lucid, and is using the pd-aubio library from that distribution, with the external copied from /usr/lib/pd/extras/ to /usr/lib/pd-extended/extras/
Literally the output from running in the terminal before crashing is:
pd ping; pd ping; ... (repeated) pd gui; pd process exited Segmentation Fault
Not very useful...
Thanks for any help... I was planning to try to use pd to control the lighting at a pretty big show next week, so this really is throwing a wrench into my plans. It would definitely be a major pain to have to reimplement this in C or something =/
Sincerely, Brian Neltner
On 23/10/10 20:36, Brian Neltner wrote:
I have attached the offending script.
Seems quite simple, but I don't have pd-extended and miss the required libraries to test.
pd gui; pd process exited Segmentation Fault
Not very useful...
You could try 'gdb' or 'valgrind' to get more useful output.
$ gdb --args pd-extended blah blah
run
Segmentation Fault
bt
(tells you where the error is, hopefully)
quit
$
See also:
http://puredata.info/docs/developer/DebuggingPdExternals
Claude
Thanks for the info Claude,
Here is what gdb eventually spit out.
I read the documentation page, but I'm afraid I don't really see what I should do from that. Is it trying to do a trace with #0 being the immediate call that crashed, while #1 is what called #0 and #2 called #1 and so on? If so, it seems that maxlib history is what is causing the problem.
Sorry, I wish I knew more about programming... Brian
On Sat, 2010-10-23 at 21:13 +0100, Claude Heiland-Allen wrote:
On 23/10/10 20:36, Brian Neltner wrote:
I have attached the offending script.
Seems quite simple, but I don't have pd-extended and miss the required libraries to test.
pd gui; pd process exited Segmentation Fault
Not very useful...
You could try 'gdb' or 'valgrind' to get more useful output.
$ gdb --args pd-extended blah blah
run
Segmentation Fault
bt
(tells you where the error is, hopefully)
quit
$
See also:
http://puredata.info/docs/developer/DebuggingPdExternals
Claude
On 24/10/10 00:22, Brian Neltner wrote:
Thanks for the info Claude,
Here is what gdb eventually spit out.
I read the documentation page, but I'm afraid I don't really see what I should do from that. Is it trying to do a trace with #0 being the immediate call that crashed, while #1 is what called #0 and #2 called #1 and so on? If so, it seems that maxlib history is what is causing the problem.
Yes, in the absence of symbol information from 'history.pd_linux', I would guess that it is these lines that are the problem:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
155 if(++x->x_inpointer > MAX_ARG) 156 { 157 x->x_inpointer = 0; 158 }
Possibly it should be >= instead of >, otherwise the code might end up reading/writing past the end of the 0-indexed arrays of size MAX_ARG, causing all kinds of memory corruption and random crashes, but I don't suggest making the change without checking whether it is correct - the code doesn't have any comments indicating the data invariants.
Sorry, I wish I knew more about programming... Brian
On Sat, 2010-10-23 at 21:13 +0100, Claude Heiland-Allen wrote:
On 23/10/10 20:36, Brian Neltner wrote:
I have attached the offending script.
Seems quite simple, but I don't have pd-extended and miss the required libraries to test.
pd gui; pd process exited Segmentation Fault
Not very useful...
You could try 'gdb' or 'valgrind' to get more useful output.
$ gdb --args pd-extended blah blah
run
Segmentation Fault
bt
(tells you where the error is, hopefully)
quit
$
See also:
http://puredata.info/docs/developer/DebuggingPdExternals
Claude
Claude
Thanks Claude for your help.
I will personally just be switching to mavg instead of history for now since I need to be confident it will work. Is there someone I can notify who maintains the history external who would be interested in knowing about the bug?
Brian
On Sun, 2010-10-24 at 00:38 +0100, Claude Heiland-Allen wrote:
On 24/10/10 00:22, Brian Neltner wrote:
Thanks for the info Claude,
Here is what gdb eventually spit out.
I read the documentation page, but I'm afraid I don't really see what I should do from that. Is it trying to do a trace with #0 being the immediate call that crashed, while #1 is what called #0 and #2 called #1 and so on? If so, it seems that maxlib history is what is causing the problem.
Yes, in the absence of symbol information from 'history.pd_linux', I would guess that it is these lines that are the problem:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
155 if(++x->x_inpointer > MAX_ARG) 156 { 157 x->x_inpointer = 0; 158 }
Possibly it should be >= instead of >, otherwise the code might end up reading/writing past the end of the 0-indexed arrays of size MAX_ARG, causing all kinds of memory corruption and random crashes, but I don't suggest making the change without checking whether it is correct - the code doesn't have any comments indicating the data invariants.
Sorry, I wish I knew more about programming... Brian
On Sat, 2010-10-23 at 21:13 +0100, Claude Heiland-Allen wrote:
On 23/10/10 20:36, Brian Neltner wrote:
I have attached the offending script.
Seems quite simple, but I don't have pd-extended and miss the required libraries to test.
pd gui; pd process exited Segmentation Fault
Not very useful...
You could try 'gdb' or 'valgrind' to get more useful output.
$ gdb --args pd-extended blah blah
run
Segmentation Fault
bt
(tells you where the error is, hopefully)
quit
$
See also:
http://puredata.info/docs/developer/DebuggingPdExternals
Claude
Claude
I tried here with trunk/externals/maxlib/history.c and attached history-test.pd patch, crashed:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6aad862 in history_float (x=0x831a80, f=<value optimised out>) at history.c:153 153 else x->x_average = x->x_input[x->x_inpointer]; (gdb) bt #0 0x00007ffff6aad862 in history_float (x=0x831a80, f=<value optimised out>) at history.c:153 #1 0x000000000046a69f in outlet_float () #2 0x000000000046ab69 in outlet_bang () #3 0x00000000004b8e04 in ?? () #4 0x00000000004761ed in m_mainloop () #5 0x000000000047aaf5 in sys_main () #6 0x00007ffff6ccec4d in __libc_start_main (main=<value optimised out>, argc=<value optimised out>, ubp_av=<value optimised out>, init=<value optimised out>, fini=<value optimised out>, rtld_fini=<value optimised out>, stack_end=0x7fffffffe238) at libc-start.c:226 #7 0x0000000000412f99 in _start () (gdb) print x->x_inpointer $1 = 4728264212663500800
I'm guessing that the array overrun dumped some garbage in the x_inpointer field, which then exploded...
with the s/>/>=/ patch to line ~155 (see below) I didn't manage to crash it, but I also don't know if the output was correct...
Claude
On 24/10/10 01:05, Brian Neltner wrote:
Thanks Claude for your help.
I will personally just be switching to mavg instead of history for now since I need to be confident it will work. Is there someone I can notify who maintains the history external who would be interested in knowing about the bug?
Brian
On Sun, 2010-10-24 at 00:38 +0100, Claude Heiland-Allen wrote:
Yes, in the absence of symbol information from 'history.pd_linux', I would guess that it is these lines that are the problem:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
155 if(++x->x_inpointer> MAX_ARG) 156 { 157 x->x_inpointer = 0; 158 }
Possibly it should be>= instead of>, otherwise the code might end up reading/writing past the end of the 0-indexed arrays of size MAX_ARG, causing all kinds of memory corruption and random crashes, but I don't suggest making the change without checking whether it is correct - the code doesn't have any comments indicating the data invariants.
Please post this to the bug tracker. Its under the Help menu, its called "report bug". Or search puredata.info for "bug tracker".
.hc
On Oct 23, 2010, at 8:05 PM, Brian Neltner wrote:
Thanks Claude for your help.
I will personally just be switching to mavg instead of history for now since I need to be confident it will work. Is there someone I can notify who maintains the history external who would be interested in knowing about the bug?
Brian
On Sun, 2010-10-24 at 00:38 +0100, Claude Heiland-Allen wrote:
On 24/10/10 00:22, Brian Neltner wrote:
Thanks for the info Claude,
Here is what gdb eventually spit out.
I read the documentation page, but I'm afraid I don't really see what I should do from that. Is it trying to do a trace with #0 being the immediate call that crashed, while #1 is what called #0 and #2 called #1 and so on? If so, it seems that maxlib history is what is causing the problem.
Yes, in the absence of symbol information from 'history.pd_linux', I would guess that it is these lines that are the problem:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
155 if(++x->x_inpointer > MAX_ARG) 156 { 157 x->x_inpointer = 0; 158 }
Possibly it should be >= instead of >, otherwise the code might end up reading/writing past the end of the 0-indexed arrays of size MAX_ARG, causing all kinds of memory corruption and random crashes, but I don't suggest making the change without checking whether it is correct - the code doesn't have any comments indicating the data invariants.
Sorry, I wish I knew more about programming... Brian
On Sat, 2010-10-23 at 21:13 +0100, Claude Heiland-Allen wrote:
On 23/10/10 20:36, Brian Neltner wrote:
I have attached the offending script.
Seems quite simple, but I don't have pd-extended and miss the required libraries to test.
pd gui; pd process exited Segmentation Fault
Not very useful...
You could try 'gdb' or 'valgrind' to get more useful output.
$ gdb --args pd-extended blah blah
run
Segmentation Fault
bt
(tells you where the error is, hopefully)
quit
$
See also:
http://puredata.info/docs/developer/DebuggingPdExternals
Claude
Claude
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
-
Brian Neltner -
Claude Heiland-Allen -
Hans-Christoph Steiner