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 <[email protected]>
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: [email protected]
[[email protected]] on behalf of Eliot Miranda
[[email protected]]
Sent: Thursday, March 22, 2012 10:49 PM
To: [email protected]
Subject: Re: [Pharo-project] Callback(?) debugging - bad number of arguments
On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K
<[email protected]<mailto:[email protected]>> 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
