catastrophic exception-handling disablement on Windows Server 2008 R2
We have found a very strange RTS bug that only manifests on some Windows machines, running Windows Server 2008 R2. It does not occur on our Windows 7 machines. We are not sure whether the installed version of Visual C runtime system matters.
The context is a ghc-compiled executable, that calls a function from a C++ DLL. The C++ function throws an exception internally, then catches it, and returns normally. The symptom of the bug is that, from ghc-7.8.1 onwards, including ghc-7.10.1, the C++ exception is not caught by the C++ code, but terminates the program catastrophically, with exit code 127. When the Haskell executable is compiled by ghc-7.2.3 or before, the bug does not happen.
If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows.
Attached to the ticket, please find (a) a C++ module, which exports a single function that throws an exception and catches it; (b) a Haskell module which imports the C++ via the FFI, and calls it; (c) a build script which compiles the C++ to a DLL, using the MSVC compiler, compiles the Haskell with ghc, and links them together.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | malcolm.wallace@me.com, simonmar |
| Operating system | |
| Architecture |