none
C++/CLI interop: Stack frames skipped, local variables not destructed on exception RRS feed

  • Question

  • I've encountered the following situation, using C++/CLI:

    Managed thread calls into native code (that is, code in a project compiled without /clr) which then calls back into managed code (via native classes/functions in a project compiled with /clr). The native code has some RAII-type local variables declared to manage some resources (critical sections, in this case) in an exception-safe manner.

    An exception is thrown from the managed code. The exception travels up the call-stack, through the native stack frames, back to the original managed stack frames and is handled. But, the destructors for the local variables in the native frames do not run.

    I see the same behavior whether the exception thrown is managed (System::Exception) or native (std::exception). I see different (correct) behavior if I put the native local variables inside a try block (the destructors run before the exception handler, presumably since they go out of scope before it). If I put try/catch blocks in the native code, but do not put the local variables inside, I see the exception handler run but the variables' destructors do not run.

    I've replicated the problem with a small test solution which I'll try to post a little later. I've replicated it in VS2005 and in VC++ 2008 Express.

    This is extremely frustrating, especially given that in other areas of our project that follow slightly different patterns (native thread calls into managed code, which calls into native code) exceptions seem to behave correctly. I'm not sure whether it's likely a compiler bug or a problem with how the CLR handles exceptions.

    Has anyone else encountered anything like this?
    Monday, March 10, 2008 10:21 PM

Answers

  • It appears I should've done a little more research first. This post covers the solution, but MSDN search didn't pick it up. Had to rely on Google Smile
    Monday, March 10, 2008 11:39 PM

All replies

  • Further notes:

    Throwing the exception out of the native code seems to exhibit the same problem, so the root of the issue might have something to do with winding up the call stack from native code to managed code.

    If I compile the "native" project with /clr the problem goes away.
    Monday, March 10, 2008 11:26 PM
  • It appears I should've done a little more research first. This post covers the solution, but MSDN search didn't pick it up. Had to rely on Google Smile
    Monday, March 10, 2008 11:39 PM