[Openmcl-devel] win32 exception compatibility

[Matthew Claus]

Thanks for your quick and thoughtful response Gary, that makes it 
perfectly clear what should probably work with this change and what 
certainly will not.

I will continue to experiment, better learn the code and try to
identify further changes necessary for the more general cases.

Regards,
Matt

-----Original Message-----
From: "Gary Byers" <gb at clozure.com>
Sent: Monday, June 1, 2009 4:36pm
To: "Matthew Claus" <matt at mclaus.com>
Cc: openmcl-devel at clozure.com
Subject: Re: [Openmcl-devel] win32 exception compatibility

I'd be shocked if this worked fully and generally, though the change
that you made is likely a necessary first step.

Suppose that some thread is executing a mixture of C[++] and lisp code
(lisp code calls C code which calls back to lisp and calls out to C,
etc.)  For GC reasons, we actually execute lisp and foreign code on
different stacks, but we can think of it as being a single stack with
alternating lisp and foreign regions.  If an exception (or lisp error)
occurs and we need to transfer control to a handler (whether that's a
lisp or foreign handler), we need to take care when unwinding the stack
to ensure that both C and foreign stacks (or stack regions) are unwound
safely (have the opportunity to run the moral equivalent of UNWIND-PROTECT
cleanup forms in the right execution context, etc.)

The same issue arises in the ObjC bridge on OSX, and we handle it (by
hooking ourselves into the ObjC runtime's exception handling mechanisms
and doing special things whenever we transition between ObjC and lisp
code.  It might or might not be possible to do similar things to get
the CCL and MSVC++ runtimes to cooperate when exceptions occur, but
there's no code in place in CCL that tries to make the right thing happen.

If you call out to some foreign code, that code establishes an exception
handler then does something that causes an exception without any lisp
code between the point where the handler was established and the point
where the exception occurred, that should work as expected (and your
change is likely necessary to maje it work.)  If there's lisp code
(callbacks) "between" the handler and the point where the exception
occurred, then any UNWIND-PROTECT cleanups in that lisp code wouldn't
run and other things may misbehave.

On Mon, 1 Jun 2009, Matthew Claus wrote:

> Hi all, let me first say thank you to everyone who has helped produce 
> and make available such an outstanding tool. I'm having a lot of fun 
> with it.
>
> I am a complete novice with Clozure CL, so please take this question in 
> that context. I'm running on 32 bit Windows XP SP2, using both the 
> release and trunk version from subversion.
>
> Is CCL fundamentally compatible with foreign C++ code (built with 
> Microsoft Visual C++) that may internally use C++ exceptions?
>
> I am calling a function in a foreign library and ending up at the lisp 
> kernel debugger. I believe this is because the Microsoft compiler 
> implements C++ exceptions with windows structured exceptions and as 
> such, any throw in foreign code results in the CCL vectored 
> exception handler being called. In this case, the debugger is 
> entered on x86-exceptions.c, line 1992.
>
> I found this article on MSDN (http://support.microsoft.com/kb/185294) 
> which identifies the exception code used by the VC compiler in implementing C++ 
> exceptions. I patched windows_arbstack_exception_handler like this: 
>
>    if ((current_sp >= cs->low) &&
>        (current_sp < cs->high)) {
>      debug_show_registers(context, exception_pointers->ExceptionRecord, 0); 
>
> -->  if(code == 0xE06D7363){ 
> -->    return EXCEPTION_CONTINUE_SEARCH;
> --> }
>      FBug(context, "Exception on foreign stack\n");
>      return EXCEPTION_CONTINUE_EXECUTION;
>    }
>
> Now my application is working fine but I'm wondering if I'm simply 
> doing something wrong in the first place, if there is a better 
> approach to solving this problem, or if calling foreign C++ code that 
> is internally using exceptions is not intended to work at this time.
>
> Thanks very much for your thoughts and assistance,
>
> Matt
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel