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:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project