Callback(?) debugging - bad number of arguments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Callback(?) debugging - bad number of arguments

Schwab,Wilhelm K
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?  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

Reply | Threaded
Open this post in threaded view
|

Re: Callback(?) debugging - bad number of arguments

Eliot Miranda-2


On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <[hidden email]> 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? 

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

Reply | Threaded
Open this post in threaded view
|

Re: Callback(?) debugging - bad number of arguments

Eliot Miranda-2


On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda <[hidden email]> wrote:


On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Callback(?) debugging - bad number of arguments

Schwab,Wilhelm K
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 <[hidden email]>
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: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
Sent: Thursday, March 22, 2012 10:49 PM
To: [hidden email]
Subject: Re: [Pharo-project] Callback(?) debugging - bad number of arguments



On Thu, Mar 22, 2012 at 7:46 PM, Eliot Miranda <[hidden email]> wrote:


On Thu, Mar 22, 2012 at 6:20 PM, Schwab,Wilhelm K <[hidden email]> 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