On Sun, 1 Feb 2009, Luke Iannini wrote:
I attached one of the crashlogs as well, which starts at "0 pd 0x00039cbe pd_typedmess + 142 (m_class.c:696)", but note that I also saw the "0 ??? ..." style crash as well that I'm assuming is indicative of corrupted memory?
"0 ???" can mean many things. It can mean that the markers in the code (which gdb calls "symbols") are not present, but barring that, it's usually that a function pointer has just been used and was wrong (for any reason including maybe memory corruption). After #0, it could also be that the stack has been corrupted such that the programme doesn't even know anymore where it's coming from, but for #0, that's not possible because that's not recorded on the stack at that moment.
There are lots of things that can be guessed from which calls are "???" and which aren't, and if you have full debugging on, you can also guess more things from whether the arguments being passed look sane or not.
If all (or almost all) entries after #0 are "???", then the stack-pointer has been corrupted, or the programme is optimised in a way that gdb doesn't understand (that's why it's easier to debug with optimisations turned off). It could also be a really bad case of stack corruption
Anyway, for this particular case... I think that the problem is a bit tricky to find. I could remove all instances of the abstraction except one and still get the crash. Then within the abstraction I could remove almost everything and still get the crash. In the end, with gdb's "break pd_bind" (and "cont" and "p (*x)->s_name->c_name)" I was able to find that it has to do with the [template] class registering itself to "".
Something weirder that happened is that I found that there are two symbols named "" (empty string) at once. Then I don't know how to go any further for now.
I made those attempts using pd 0.40-2.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec