debugging perl bindings on a C library

[dkg]

hey good people--

I'm trying to debug problems with Crypt::GCrypt -- a module which is effectively a wrapper around a C library.

I find the debugging process difficult and confusing in this scenario -- the source that i've got is the .xs file, which i can't get either the perl debugger or gdb to treat as "source". So far i've figured out the following two (suboptimal) techniques for dealing with problems i encounter:

• i step through a test script with perl -d t/00-test.t, and attach to the process with gdb after the first line. I insert breakpoints based on the generated .c file to try to get more information about the internal state of the system
• i write a test C program that does (what i think is) the same thing as the perl program, and step through that, and try to guess at a good analogy of what's happening

Are there better techniques for debugging this kind of perl module? If so, what do you use? What tools or options should i be considering and reading up on?

[Joost]

First: if you're using a distro supplied perl, make sure you've got the perl-debug package installed. Same goes for the debug package for libgcrypt.

Second: you can use valgrind to get at least some kind of indication of where any segfaults and badly allocated memory segments are located, if you've got that kind of problem.

Third: reduce the 00-test.t file to the absolute minimum where it'll still shows the problem. .xs files normally don't contain that much code and it should be possible to figure out where the problem is from any stack traces or manually tracing what calls are made across the perl/C boundaries. You can also put croak() or printf() calls in the XS code if you want more direct reporting of what's going on.

[salva]

First: if you're using a distro supplied perl, make sure you've got the perl-debug package installed

... otherwise, just compile your own debugging perl. It is quite easy:

1. Get the http://ftp.cpan.org/pub/CPAN/src perl source from CPAN
2. Unpack it and cd into the directory
3. Run ./Configure accepting the defaults for all the questions but these two:
   1. Where do you want to place the debugging perl?, for instance:
      Installation prefix to use? (~name ok) [/usr/local] /usr/local/perl/5.10.1-debug
   2. Which C optimizer flags to use:
      What optimizer/debugger flag should be used? [-O2] -g -O0
   3. well, maybe you would like to also activate threads or other minor features.
4. make && make test && sudo make install
Then, to compile your module using this new perl, all you have to do is run Makefile.PL with it. For instance:

$ cd Foo-Bar-1.0
$ /usr/local/perl/5.10.1/bin/perl Makefile.PL
$ make
$ make test

[dkg]

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.

[Joost]

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.