Eliot, I did some more looking at the code, added a method to control when thing halt. The callback methods get exercised two ways: as ordinary methods with FFI objects, and then as actual callbacks with Alien parameters. I abstracted wrapping the arguments as arrays and matrices. What I had overlooked elsewhere was that I fell into the old trap of doing something like solver set:callback thunk address (or whatever the right incantation is). The point is that something is probably getting gc'd before activity dies out. With suitable temp variables to hold things, I got further. It's now it is seg faulting in a GSL call via FFI. Below is what I think is relevant from the crash dump. #set:set:set:guess: appears to be hitting the callbacks (successfully according to the debugger), and conks out "on the way out" of the FFI call that triggers everything. I need to set intermediate breakpoints in that method to see if it really is blowing up where I suspect. Any other ideas? Thanks! Bill ------------------------------------------------------------- Segmentation fault Thu Mar 22 22:59:14 2012 Squeak VM version: 3.9-7 #1 Mon Feb 20 23:15:24 CET 2012 gcc 4.1.2 Built from: CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Feb 20 2012 With: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 Feb 20 2012 Revision: https://git.gitorious.org/cogvm/blessed.git Commit: 0f55a39cb3f41907fca6d102845154da5dfa597f Date: Mon Feb 20 18:59:49 2012 -0300 By: Esteban Lorenzano <estebanlm@gmail.com> Build host: Linux pharo-build.lille.inria.fr 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 14:13:46 EST 2010 i686 i686 i386 GNU/Linux plugin path: /home/bills/Work2012/Pharo-1.3/ [default: /home/bills/Work2012/Pharo-1.3/] C stack backtrace: /home/bills/Work2012/Pharo-1.3/CogVM[0x80968b1] /home/bills/Work2012/Pharo-1.3/CogVM[0x8096a3c] [0xb774e410] /usr/lib/libgsl.so.0(gsl_multifit_fdfsolver_set+0xdd)[0x75a2a72d] /home/bills/Work2012/Pharo-1.3/libSqueakFFIPrims.so(primitiveCallout+0x4b2)[0x75c962a2] /home/bills/Work2012/Pharo-1.3/CogVM(interpret+0x3f68)[0x808dcc8] /home/bills/Work2012/Pharo-1.3/CogVM[0x808fc97] /home/bills/Work2012/Pharo-1.3/CogVM[0x8090664] /home/bills/Work2012/Pharo-1.3/CogVM(main+0x38a)[0x809774a] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb75aebd6] /home/bills/Work2012/Pharo-1.3/CogVM[0x805acc1] Smalltalk stack dump: 0xbfd96e20 I GSLNonLinearLeastSquaresWithDerivatives>set:set:set:guess: 2035750124: a(n) GSLNonLinearLeastSquaresWithDerivatives 0xbfd96e68 I GSLModelGaussianPlusConstant(GSLModel)>fit: 2035750096: a(n) GSLModelGaussianPlusConstant 0xbfd96e90 I GSLModelGaussianPlusConstant class>example 2026112964: a(n) GSLModelGaussianPlusConstant class 0xbfd96ea8 M GSLModel class>? 2026110492: a(n) GSLModel class ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda@gmail.com] Sent: Thursday, March 22, 2012 10:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Callback(?) debugging - bad number of arguments On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda <eliot.miranda@gmail.com<mailto:eliot.miranda@gmail.com>> wrote: On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, I am calling something that I *think* simply tells GSL where to find the callbacks and a relevant structure. But I am getting a primitive failure in VMCallbackContext32>>primReturnAs:fromContext:, which I assume means that the library is attempting to call into Pharo. In the debugger's context, ec is set to #'bad number of arguments'. I have looked at the signatures and the blocks, and the argument counts look correct at first glance, albeit toward the end of a long day. Am I being naive? Uh, ignore my reply. It was confused and wrong. Alas can't attend to this right now (dinner calls and it's a school night). Apologies.... later... Understandably so. I believe the issue is the callback selector in place in recreateSpecialObjectsArray. It needs to be newArray at: 54 put: #invokeCallbackContext:. not the older newArray at: 54 put: #invokeCallback:stack:registers:jmpbuf:. And you need to have invokeCallbackContext: implemented in Alien class. HTH Any better ideas? My next inclination is to set breakpoints in all of the callbacks to seee if any of them get hit. I can't see why they would, but it's possible - especially given other weirdness that I have observed in GSL. It work, but it's a little rough around the (design/elegance) edges at times. Bill -- best, Eliot -- best, Eliot