I wrote...
I'm getting a segfault deep in the middle of a large test suite, on
an app that uses a bunch of recursion. Isolating this probably
isn't going to be easy.
Any ideas on how I can get a nice, verbose stack trace, a la the
Carp module's confess?
No response from the list, so I forged ahead.
I ended up adding a labeling printf line for each function, plus an
incrementor. The resulting mess got me close enough that I could
figure out what data was being accessed when the segfault occurred,
and luck and tenacity got me from there to the source of the problem.
Another segfault which emerged later was due to the reference count
on an SV going to 0; after localizing the problem using the same
function labels, Devel::Peek's Dump function helped me figure out
what was going wrong.
I'm a fairly sophisticated Perl hacker, but my C skills haven't been
tested on this ambitious a project before. The O'Reilly book I
taught myself from, "Practical C Programming" by Steve Oualline,
doesn't offer any guidance on debugging memory issues. The C part of
the application I'm working on isn't horrendously complex (the tricky
bits are in the Perl code that calls the C stuff), but there's a lot
of pointer math, and fencepost errors which would generate copious
warnings in Perl trigger the maddeningly concise "segmentation fault"
death in C.
In the hopes of saving myself time next trip down the memory-
corruption-debugging road, I'll make a more general inquiry:
Where do you start when debugging this kind of problem? I see
mention made here and there to gdb, coredumps, valgrind, and such,
and there are a few tools referenced in the Perl documentation (e.g.
Poison), but I haven't found "the answer" yet. "The answer" is going
to be something which allows me to identify a source code line number
or equivalent for when the segfault occurs. But it might also
comprise debugging disciplines which are necessary for C but
irrelevant for languages which hide memory management from the
programmer like Perl. I am certain that there are well established
routines for memory debugging, and I marvel at the fact that
Practical C Programming omits them.
There has *got* to be a better way.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
