Having no experience working with the nuts and bolts of Perl, all advice I can give you is a classic you probably have thought of as well. If the program segfaults, you should have a core file. Running this corefile through a debugger should get you some information, such as where you are getting your segfault (i.e. in which function), what the call stack leading to that function was, and the values of (C level) variables at that point. It helps if your library is compiled with -g (to add debugging information), but even without this you should get some information.
Here's how to do some of this with gdb on Linux, YMMV for other debuggers:
$ gdb -c core /usr/local/bin/perl
[snip]
(gdb) set args my_test_script.pl
(gdb) run
...something about segfaulting
(gdb) where
... shows what function you were in
(gdb) bt
... shows a backtrace of the stack, showing the code path to this func
+tion
(gdb) print variable
... prints variable, amazingly (supposing it is in scope)
(gdb) print *0xdeadbeef
... prints memory address contents (best guess at what it contains)
It is my experience that this usually puts me well on the way of finding the exact bug: at the least it shows you where to look.
Good luck!
Update: added asterisk before Oxdeadbeef.
CU
Robartes- | [reply]
[d/l] |
Thanks. I've always been more of a print "X" debugger.
I've never really used core files for debugging. Long ago when I actually did ASM and C, I was using Windows so I never had the experience. I knew what the core files where and that they could be used for debugging but had not idea how to use them for this.
Thank you much.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Thanks again. It's showing me that the problem is in SafeFree. (The address it's trying to free isn't changing so it must be a foobar pointer.)
-Lee
"To be civilized is to deny one's nature."
| [reply] |
It is definitely easier if you have the perl source available. It has been a long time since I have done this, but you should be able to compile it all with -g (and -DDEBUGGING) to enable the debugging stuff, and do
gdb /my/debugging/perl
(gdb) run my_script my_args
To make your life even easier, while you are recompiling your perl, link your .xs module in statically -- it will make setting breakpoints and the like easier, because your module will be loaded in from the get-go.
Another little trick is to use the perl debugger too:
gdb /my/debugging/perl
(gdb) run -d my_script my_args
Hitting Ctl-C from the perl debugging prompt will (or at least should...) drop you back down into the gdb prompt. (click here for a post showing an example of this trick in use...)
It should also work with dbx or any other C-level debugger.
Best of luck...
--JAS | [reply]
[d/l]
[select] |