Tracing on Linux

I am trying to track down a segmentation fault in calling into the Gnu Scientific Library.  These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux.   Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed.  That is all the more true of new functions that I am adding for testing purposes.

The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them.  A wrapper .so that is  linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own.

I went so far as to compile some GSL sample code, and it does not crash.  I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening).  I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI.

On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem.  How do you unix VM gurus tackle such debugging problems?

Bill

Hi Bill,

If you are on a system with DTrace support you can use its function entry and function return probes (http://wikis.sun.com/display/DTrace/pid+Provider) to see what is going on in the C code. In case it helps to link this information with Smalltalk execution, you can use the Squeak/Pharo probes as described in my blog http://adrian-lienhard.ch/blog.

Cheers,
Adrian


On Jul 11, 2010, at 23:30 , Schwab,Wilhelm K wrote:

 
On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote:
>
> I am trying to track down a segmentation fault in calling into the Gnu Scientific Library.  These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux.   Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed.  That is all the more true of new functions that I am adding for testing purposes.
>
> The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them.  A wrapper .so that is  linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own.
>
> I went so far as to compile some GSL sample code, and it does not crash.  I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening).  I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI.
>
> On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem.  How do you unix VM gurus tackle such debugging problems?
>

Bill,

To write strings to output, use fprintf() followed by fflush().
Don't forget the fflush or you'll never figure anything out ;)

To use a debugger, compile with CFLAGS=-g (enable debugging
info, no compiler optimization), then run the VM under gdb or
one of the gui front ends to gdb such as ddd. Put a breakpoint
in your function, and you're good to go.

Assuming you are using up to date sources from Subversion, run
"platforms/unix/configure --help" for more build options.

Dave