----- Original Message -----
From: "Marvin Humphrey" <[EMAIL PROTECTED]>
>
> 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.
That's the only method I've ever used. It has always worked so I've looked
no further :-)
You can '#define DEBUG' and put your printf's inside '#ifdef DEBUG' blocks.
Then when you're finished, instead of having to find and remove them all,
you have simply to remove '#define DEBUG'. (And that way the printf's are
still there if you find you need them again later.)
>
> 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.
You can also 'printf("%d\n", SvREFCNT(sv));' to view the reference count
from within the C function. I've made use of that from time to time
(particularly wrt operator overloading, where I'm often not sure just what
the count is).
Another perl module I've seen mentioned is B::Debug - but I haven't used it.
> The O'Reilly book I
> taught myself from, "Practical C Programming" by Steve Oualline,
> doesn't offer any guidance on debugging memory issues.
There is no generic C debugger, and hence no generic methods of C
debugging - except for using printf() statements. The book that I have
advises to either use the vendor-supplied debugger, or use printf
statements - and that's about the only debugging advice that can be offered.
They can't tell you how to use the C debugger, because they don't know which
one you have (and they probably don't feel like covering all of them -
actually, they're probably relieved that they don't have to cover *any* of
them :-)
>
> There has *got* to be a better way.
>
I know people do use gdb and Valgrind.
There are no doubt other useful B::* and Devel::* modules available, too -
for debugging, anyway, if not specifically for segfaults (check CPAN). It's
probably a good idea to have a perl built with debugging (-Doptimize='-g').
You'll certainly want that if you decide to use gdb, and many of the other
debugging aids provide enhanced info when used with such a perl.
Heh ... I've only just now seen Eric's post. Like him, the main reason I
didn't post was that I didn't feel qualified. I actually did write a reply
to your initial post, but then thought "naaaaaaaaaa ...". Sorry if my
timidity meant extra work for you :-)
Cheers,
Rob
