Re^2: debugging perl bindings on a C library

thanks! I have the debug package for libgcrypt already (libgcrypt11-dbg on debian), but didn't have perl-debug installed yet. i'm installing it now and i'll poke around in it to see what's available to me there.

my problem at the moment is not a memory issue, so valgrind's not needed right now, but i'll keep that for future reference.

how do you suggest i look at the stack traces or trace calls across perl/C boundaries other than what i've been doing so far? is there some other trick beyond what i'm currently doing? the approach i described above feels kludgy to me, but maybe i'm just not used to it enough yet.

Comment on Re^2: debugging perl bindings on a C library

Replies are listed 'Best First'.
Re^3: debugging perl bindings on a C library by Joost (Canon) on Oct 22, 2009 at 23:37 UTC
I don't know what the issues you're having are, so I can't be too specific, but I'm assuming you're trying to fix a bug in the perl/XS binding to the library, assuming the C library (and the perl binary!) are working correctly. My first stab at these kinds of problem is usually to put a bunch of assert() statements in the XS code, compile the module making sure that NDEBUG is undefined, and rerun the test. That should halt the code at any moment the assertions don't hold, and should tell you at least where your assumptions are wrong, and I think it would also give you a break point in GDB, though I must confess I don't really use debuggers at all, except to inspect core dumps. I'm not a wizard with perl internals or C, but just getting in the code and trying to confirm my expectations works most of the time when dealing with algorithmic mistakes. In my experience, memory allocations etc errors are actually harder to find, which is why I like valgrind so much. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]

Replies are listed 'Best First'.

Re^3: debugging perl bindings on a C library
by Joost (Canon) on Oct 22, 2009 at 23:37 UTC

My first stab at these kinds of problem is usually to put a bunch of assert() statements in the XS code, compile the module making sure that NDEBUG is undefined, and rerun the test. That should halt the code at any moment the assertions don't hold, and should tell you at least where your assumptions are wrong, and I think it would also give you a break point in GDB, though I must confess I don't really use debuggers at all, except to inspect core dumps.

I'm not a wizard with perl internals or C, but just getting in the code and trying to confirm my expectations works most of the time when dealing with algorithmic mistakes. In my experience, memory allocations etc errors are actually harder to find, which is why I like valgrind so much.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

[reply]