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

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of David T. Lewis
> Sent: Monday, July 12, 2010 5:32 AM
> To: Squeak Virtual Machine Development Discussion
> Cc: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> David T. Lewis
> Sent: Monday, July 12, 2010 5:32 AM
> To: Squeak Virtual Machine Development Discussion
> Cc: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> David T. Lewis
> Sent: Monday, July 12, 2010 5:32 AM
> To: Squeak Virtual Machine Development Discussion
> Cc: [hidden email]
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project