On Tue, 2004-09-07 at 09:01, Bob Jamison wrote:
I have noticed this, also, that the last few lines of the backtrace are often incorrect, and that the cause might be elsewhere. Maybe this is the real effect of a 'stack corruption', and we are seeing it. Several times recently gdb has reported a segfault in fill-style.cpp, when I -know- that it is not there at all.
I've noticed that a common thread among the various crashes is that they happen in a specifically malloc()-related context (at least the ones I've seen personally, and I think also the sigc++ crashes).
I'm wondering whether something is writing out of bounds and corrupting the malloc headers. I have tried testing for this using ElectricFence, but at least on my machine we allocate too many small blocks with EF to make it all the way through startup. (not a bug on our part, just an annoying limitation of EF)
Anyway, if the malloc data structures are getting corrupted, stack corruption might easily follow on from that.
As far as potential culprits? libgc itself should be immune to corruption as it does not try to write to memory it does not manage, but of course if its own header structures are corrupted, it could theoretically stomp on something else.
Otherwise, the only other (obvious) possibilities I can think of are (in decreasing likelihood):
1) I screwed up the definition of Inkscape::GC::Finalized, and it's not using the right value for 'this' when calling the destructor.
In this case, introducing sigc++ signals to SPReprDoc (derived from Inkscape::GC::Finalized) could well result in heap corruption when the object was destroyed, since the signal destructors try to free memory and their internal pointers would be wrong.
2) livarot is corrupting the malloc headers, and it's pure luck that we have not been caught by it before.
livarot fails to check for array indices of -1 in many places where they may occur. I've caught it reading from such locations in malloc()ed arrays; it's certain that if it ever writes to them it will corrupt the heap.
Such corruption might be hard to detect, and only result in dramatic failures with specific usage patterns (like the allocation sequence introduced by the new sigc++ signals).
-mental