Windows: How to catch C++ exceptions in runtime-compiled code?

HI all,

Here in the JUCE team, we are working on porting the Projucer C++ live coding engine to Windows. Our main challenge now is how to catch C++ exceptions in runtime-compiled code on Windows. This doesn’t work for us and we’re quite stuck at this point.

I recently had a chat about this with Chandler Carruth at C++Now. Chandler suggested that we post our problem to this mailing list, and that perhaps Reid Kleckner and/or other people here may have some hints. Any ideas would be highly appreciated!

In our case the RaiseException API function does not find the correct catch pad, which may be caused by a ThrowInfo structure handed to _CxxThrowException being empty. Apart from getting this right, is there anything else we possibly miss? Windows API functions to be called for registering catch pads or so?

Some more details:
We’re using Clang for compiling C++ code at runtime and the ORC libraries to load and execute it in our application, which is itself compiled with MSVC. We work with the release_38 branches of LLVM and Clang.

Static compilation of a simple test program with try/catch and throw works fine. When compiling the same code at runtime and loading it with the ORC libraries, every throw results in an unhandled exception. The point of interest seems to be the throw handler for C++ exceptions (throw.cpp):

__declspec(noreturn) extern “C” void __stdcall
_CxxThrowException(void* pExceptionObject, _ThrowInfo* pThrowInfo)
{

RaiseException( ThisException.ExceptionCode,
ThisException.ExceptionFlags,
ThisException.NumberParameters,
(PULONG_PTR)&ThisException.params );
}

For some reason the call to RaiseException does not find or consider the existing catch handler correctly. Comparing execution states when entering the function between the two cases, static- vs. runtime-compiled, turns out that pThrowInfo points to nulled memory in the runtime-compiled case, while it has some data in the static-compiled case. Detailed information about the types can be found here:

To find out why the ThrowInfo structure is empty in the runtime-compiled case, we compared what happens during code generation. It looks like CodeGenFunction::EmitCXXThrowExpr is the relevant function here and it does the right thing, i.e. generating the global variable for the ThrowInfo in MicrosoftCXXABI::emitThrow. Also the WinEHPrepare pass is running correctly as it seems. Is there any extra work to do (at runtime/link-time?) for filling this data structure? Any idea what else to check?

Our Clang language options do include: Exceptions, CXXExceptions, RTTI, RTTIData

Please reply to my colleague Stefan Gränitz (in Cc) who is in charge of this project. Any kind of help or ideas would be really awesome.

Many thanks!
Timur

Hi, Timur. I may be wrong, but it seems that I faced similar problem before. 

The problem is that Windows checks memory region of exception handler for MEM_EXECUTE_OPTION_EXECUTE_DISPATCH_ENABLE flag, that is not set by default and can't be set easily.

Before Windows passes control to your handler it does the following checks:

KiUserExceptionDispatcher ->RtlDispatchException -> RtlIsValidHandler (FAIL)

So you need to enable this flag for your memory-generated code. As far as I know it is impossible if permanent DEP is enabled. So you can either run your process without DEP (not an option in the most cases), or use another way to deal with exceptions. One of the possible workarounds is VEH. You can look through OpenJDK as an example.

Hey Igor,

Thanks a lot for your e-mail! I am Cc’ing Stefan Gränitz who is the one actually working on this project, hope this will be helpful.

Cheers, Timur

Hi Igor! Thanks for sharing your experiences.

[...] or use another way to deal with exceptions. One of the possible workarounds is VEH

Good point, with VEH I can actually catch exceptions and use sjlj to
continue on a valid instruction! It allows us to implement a safe return
from exceptional code. For the moment that's an acceptable workaround!
Thanks!

You can look through OpenJDK as an example.

Btw. just found a compact VEH implementation in
llvm::CrashRecoveryContext. And it works out if the box! Great!

See
http://llvm.org/docs/doxygen/html/CrashRecoveryContext_8cpp_source.html#l00144

The problem is that Windows checks memory region of exception handler for MEM_EXECUTE_OPTION_EXECUTE_DISPATCH_ENABLE flag, that is not set by default and can't be set easily. [...] So you need to enable this flag for your memory-generated code. As far as I know it is impossible if permanent DEP is enabled.

Yes, this doesn't sound like a good option for us right now, but I think
it's useful to keep it in mind.. so I tried the following and it still
doesn't work:
* disable DEP via "bcdedit /set {current} nx AlwaysOff" (described in
http://www.thewindowsclub.com/disable-data-execution-prevention)
* reboot
* set MEM_EXECUTE_OPTION_EXECUTE_DISPATCH_ENABLE flag programmatically
via NtSetInformationProcess (based on
https://github.com/Sh1ft0x0EF/metahook/blob/master/sys_launcher.cpp#L65)
* runtime-compiled catch handler is still not considered

I have no clue what's missing here. Any ideas?

Best,
Stefan