[Openmcl-devel] Does CCL32 still mishandle some exceptions when running on 64bit Windows?

[Gary Byers]

The bug discussed in the message from last summer had to do with (as you say)
failing to distinguish between (essentially) hardware-level exceptions and
"exceptional situations" raised by various MS language runtimes.

There were a couple of attempts to fix this

<http://trac.clozure.com/ccl/changeset/15857/trunk/source/lisp-kernel/x86-exceptions.c>

tried to stop being confused by the fact that MS language runtime exceptions
had their "customer defined" bit set, and that change seemed to fix the problems
that I was seeing.

A slightly later change:

<http://trac.clozure.com/ccl/changeset/15873/trunk/source/lisp-kernel/x86-exceptions.c>

tries to detect whether or not the exception is something that CCL's exception
handler potentially could handle and lets any other handler deal with other cases.
The wx86cl.exe and wx86cl64.exe binaries in the trunk incorporate this later
change.

The class of things that CCL "could" handle (illegal instructions, memory access
faults, arithmetic errors like division by zero ...) are more likely to be handled
if the handler can detect that the thread was running lisp code when the exception
occurred; if CCL's handler can't handle an exception, it'll drop into the kernel
debugger.  (On Windows, it might make sense to try to pass the excption to any
other handlers; I don't know if C++ or .NET exception handlers can recover from
memory faults of illegal instructions or the kinds of things that CCL's handler
is interested in, but it might be more straightforward to attach a debugger in
that case.)

So: prior to the changes described above foreign code that used some MS language
runtime faclities could sometimes cause CCL's kernel debugger to report that
it couldn't handle an exception that it shouldn't have tried to handle.  There
were and still are other situations that could cause  the kernel debugger to
be entered (e.g., a memory fault or illegal instruction in foreign code), and if
you're running the current trunk such an other situaton seems like the more
likely explanation.


On Tue, 29 Oct 2013, Paolo Micossi wrote:

> I am experimenting with hosting third party ActiveX controls (using the "AtlAxWin" container from atl.dll) with CCL.
> This has been surprisingly easy, except for lots of troubles with exception handling.
> While some ActiveX controls worked fine others (and among them the one that motivates my work the most) would crash into the kernel debugger as soon as i tried to create their window. I slowly uncovered that this happened because CCL would try (and fail) to handle some exception that could be easily handled by the C++ runtime/OS/whatever if it was left to its own devices.
>
> I searched the mailing list and found a short thread from last August which pointed me to a revised CCL kernel in the trunk that addressed exactly this point.
>
> And in fact it works, and I can now create control host windows without crashing, but there is still a problem.
>
> The ActiveX control I need most (an interface to a motor controller from Thorlabs which i want to operate from CCL) exists only in 32bit version, so i must load it using CCL32. I can create the ActiveX host window  when running CCL32 under both 64 bit Windows 7 (development PC) and 32bit Windows XP (deployment PC). I connect to the control IDispatch interface and can get/set properties on both systems.
>
> But some method invocations which work fine on 32bit XP fail into the kernel debugger on the 64bit system. Therefore i suspect that some runtime exceptions are still mishandled when CCL32 runs on a 64bit system. This MSDN page in fact hints at some subtle difference in 32bit exception handling when running on 32- or 64- bit systems:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/gg507671(v=vs.85).aspx
>
>
> Paolo Micossi
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>