[Pharo-project] 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:
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
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
Dave, Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 5:32 AM To: Squeak Virtual Machine Development Discussion Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote:
Dave,
Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar?
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 5:32 AM To: Squeak Virtual Machine Development Discussion Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote:
Dave,
Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar?
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 5:32 AM To: Squeak Virtual Machine Development Discussion Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think I found it. Trying to do this without callbacks in hand lead me to use a lot of C where I previously used block closures (that is not all bad, but it should not be necessary). As a result, I jam the data into a void pointer that is part of the library-designed function signature; with callbacks and closures, I simply shared the data inside the Smalltalk image and ignored the offending pointers. In this design, I put the points in a matrix that they treat as void* and therefore immediately indirected the pointer in the functions - big mistake, as they initially call the functions (for reasons I can't quite figure out) before the solver is configured and the data is known to the library. The pointer is therefore null and indirecting it was zapping me. A grander design might later reveal itself, but for now, it looks like a really sloppy part of the library. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, July 12, 2010 4:34 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote:
Dave,
Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar?
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 5:32 AM To: Squeak Virtual Machine Development Discussion Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Adrian Lienhard -
David T. Lewis -
Schwab,Wilhelm K