# The following was supposedly scribed by # Marvin Humphrey # on Monday 27 June 2005 06:22 pm:
>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. d'oh! Did I let this go that long? Sorry Marvin, I didn't have a really good answer for you, but could have told you to do (roughly) what you've done. >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. I usually end-up just sprinkling printf's around where I think the problem is. The portable macro version of this can be found at: http://scratchcomputing.com/svn/Math-Geometry-Planar-GPC/trunk/code/Math/Geometry/Planar/GPC/Polygon/functions.c Important bits of that are like so: // #define DEBUG_PRINT #ifdef DEBUG_PRINT #define dbg_p(x) printf x #else #define dbg_p(x) #endif ... dbg_p(("running destroy for %d contours\n", p->num_contours)); ... // I got errors from the Win testers about this when using vararg macros, so note the extra (ick) parentheses around the dbg_p() calls. >Another segfault which emerged later was due to the reference count >on an SV going to 0; I don't think I've ever had that problem. It might be that the layout of my code never gave me the opportunity (I use oo inline a lot.) >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. Forget that, you just need the K&R book (and that doesn't help with debugging either.) >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. Right. You're probably going to want to learn gdb or another C debugger. This is what I was thinking when I saw your post, but I thought that surely someone more educated than myself would have answered you by now. As I understand it, you can debug a perl extension in the same way that you would debug perl itself. That means that you're going to have to build a perl with debug flags. This little gem from 'gg:inline perl debug' is the reason that I didn't feel qualified to answer you: http://mail-archives.apache.org/mod_mbox/perl-docs-cvs/200305.mbox/<20030528064302.58086.qmail%40icarus.apache.org> --Eric -- "It works better if you plug it in!" --Sattinger's Law --------------------------------------------- http://scratchcomputing.com ---------------------------------------------
