Crash during exception translation using Intel Compiler 9.1 and optimized builds
We're using the framework to translate C++ exception to Python exceptions. The code works in debug builds but crashes in optimized builds. Were using Intel Compiler 9.1 on Windows. Has anyone experienced this? Any possible workaround? The symptoms are: - a crash under _is_exception() in MSVCR80.DLL, called from handle_exception_impl(). - The bottom of the stack is obviously bad: below _is_exception_typeof() we find tanhf (float's hyperbolic tangent? Microsoft obviously found a new type-system theorem involving high-level maths), then a long boost template and 0x0. - The arguments received in the long boost::python type (which I cannot see because the name is too long for windbg) are a0, a1 and f, and f is 0 (which might explain to jump to 0x0). Currently the only work-around we've found is to disable the exception translation. From the look of the stack, it seems that the problem is in the linked list of translators. Could it be an order-of-initialization issue? Or a temporary value that should stick around or that the compiler mistakenly optimizes away?
Pierre Baillargeon <pbaillargeon@innobec.com> writes:
We're using the framework to translate C++ exception to Python exceptions. The code works in debug builds but crashes in optimized builds. Were using Intel Compiler 9.1 on Windows.
Has anyone experienced this?
Any possible workaround?
The symptoms are:
- a crash under _is_exception() in MSVCR80.DLL, called from handle_exception_impl().
Almost certainly a compiler bug unless your own code is corrupting memory and/or code.
- The bottom of the stack is obviously bad: below _is_exception_typeof() we find tanhf (float's hyperbolic tangent? Microsoft obviously found a new type-system theorem involving high-level maths), then a long boost template and 0x0. - The arguments received in the long boost::python type (which I cannot see because the name is too long for windbg) are a0, a1 and f, and f is 0 (which might explain to jump to 0x0).
Currently the only work-around we've found is to disable the exception translation. From the look of the stack, it seems that the problem is in the linked list of translators. Could it be an order-of-initialization issue? Or a temporary value that should stick around or that the compiler mistakenly optimizes away?
Could be almost anything. Are you trying to run python code at C++'s static initialization time? If so, I could imagine an order-of-initialization issue. If not, not. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
Pierre Baillargeon <pbaillargeon <at> innobec.com> writes:
We're using the framework to translate C++ exception to Python exceptions. The code works in debug builds but crashes in optimized builds. Were using Intel Compiler 9.1 on Windows.
Has anyone experienced this?
Any possible workaround?
The symptoms are:
- a crash under _is_exception() in MSVCR80.DLL, called from handle_exception_impl().
Almost certainly a compiler bug unless your own code is corrupting memory and/or code.
Indeed, I found by trial and error that reducing the aggressiveness of inlining fixed the problem. By switching from "inline whatever the compiler wants" to "inline only function specified as inline" it fixed the problem. We are also using explicit template instantiation, but I do not know if it is a factor in triggering the problem. (We also had problem with compiling 64-bits debug version of boost.python: when we did the std::string converter stopped working, but we didn't investigate that part. Especially since we use version 1.32 of boost and had to work quite a bit to get BJam to compile in 64-bits with that release. But that's another story.)
Pierre <pbaillargeon@innobec.com> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
Pierre Baillargeon <pbaillargeon <at> innobec.com> writes:
We're using the framework to translate C++ exception to Python exceptions. The code works in debug builds but crashes in optimized builds. Were using Intel Compiler 9.1 on Windows.
Has anyone experienced this?
Any possible workaround?
The symptoms are:
- a crash under _is_exception() in MSVCR80.DLL, called from handle_exception_impl().
Almost certainly a compiler bug unless your own code is corrupting memory and/or code.
Indeed, I found by trial and error that reducing the aggressiveness of inlining fixed the problem. By switching from "inline whatever the compiler wants" to "inline only function specified as inline" it fixed the problem.
I hope you can make a report to Intel and get them to fix the bug. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Pierre -
Pierre Baillargeon