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