[Vm-dev] Re: [Pharo-dev] catching FFI errors

[Eliot Miranda]

Hi Ben,

On Sep 25, 2014, at 5:50 PM, Ben Coman <btc at openInWorld.com> wrote:

> 
> I had a brief moment wondering about the general problem we have when calling out through FFI that we expose ourselves to bugs in the external library that crash the Image.  I wonder...
> 
> 1. Debuggers like gdb can run a program that crashes, without themselves itself crashing.  Could our FFI calls be wrapped in similar mechanism?
> 
> 2. Languages have exception handling, so that errors like divide by zero can be caught.  Could our FFI calls be wrapped in similar mechanism? 
> cheers -ben

one thing that is pretty straight-forward to do is to catch and report errors during FFI calls as primitive failures with error codes.  I added this to the VisualWorks VM a while ago  It works like this:

1. The VM installs a first-level exception handler (windows) or signal handlers for SIGSEGV et al (unix). (This is something the VM already does).

2. When an FFI call out is made the VM  can find the activation they made an FDI call out.  It must be able to do this if it is to handle a callback.

3. An FFI call out is modified to set a flag, eg inFFICall, that is tested by the first-level exception handler.  The flag is cleared when the FFI call completes or cleared when taking a callback and restored when the callback returns.

4. When the first level exception/signal handler is invoked it tests the inFFICall flag.  If unset it does what it always did (exit, do nothing, etc).  If the flag is set it collects the error information, located the FFI activation for the FFI call, does a long jump that returns from the FFI call as a primitive failure, supplying the error information.

Now this is useful because the VM doesn't crash (provided the error was localized in its effects and didnt eg corrupt the heap), and hence easy for the developer to find out which FFI call provoked the error, but not as useful as catching the error in gdb.  The exception info is typically an exception code and an address, which may be difficult for the programmer to decode.  Hence the mechanism needs to be made optional, typically in by default, and then disabled to investigate under gdb.

Does this sound useful?

Eliot (phone)