On Sun, Mar 25, 2012 at 9:55 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

I started asking whether the setter function might somehow not be visible through my wrapper .so.� Running

objdump -T /home/bills/Work2010/gslWrapper/bin/Release/libgslWrapper.so | grep gsl_multifit_fdfsolver_set

gives nothing, but my experience has been the wrapper "magically" exports everything from blas and gsl, but I'm not sure how to list all of the exports.

Regardless,

�� Alien
�� lookup:'gsl_multifit_fdfsolver_set'
�� inLibrary:'libgslWrapper.so'

returns an Alien with a handle, so can I assume that the function is indeed exported by the wrapper?

yes. �But have you thought to confirm by trying

�Alien�

�� lookup:'this_is_not_in_the_library'
�� inLibrary:'libgslWrapper.so'

Bill

From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu]
Sent: Sunday, March 25, 2012 12:36 PM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] FFI error message: Heisenbug

I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code.� Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error.

In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't look<g>) that says 'No module to load address from'.� Anybody know what that means?� I'm using the CogVM on Ubuntu Lucid.

Bill