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