Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: debugging perl bindings on a C library

by Joost (Canon)
on Oct 22, 2009 at 21:02 UTC ( [id://802797] : note . print w/replies, xml ) Need Help??

in reply to debugging perl bindings on a C library

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.

  • Comment on Re: debugging perl bindings on a C library

Replies are listed 'Best First'.
Re^2: debugging perl bindings on a C library
by salva (Canon) on Oct 22, 2009 at 23:34 UTC
    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 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
Re^2: debugging perl bindings on a C library
by dkg (Acolyte) on Oct 22, 2009 at 22:17 UTC
    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.

      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.