FreiK's WebLog : Bugs

How to use RtlUnwindEx

Kevin Frei — Thu, 15 Mar 2007 18:24:00 GMT

Disclaimer: I've never actually written an unwind personality routine, so take what's here with a grain of salt.

A few days back, I spent 30 minutes defending the C++ runtime's exception handling personality routine to the guy that has the less than enviable job of supporting the .Net Framework's exception handling personality routine. The eventual point to be learned is that the documentation for RtlUnwindEx is abysmal, and can cause the VC 8.0 C++ runtime to leak objects left and right.

The problem revolves around the C++ team's decision (which I fully support) to cause code compiled with /EHs or /EHsc flags to only invoke destructors when a C++ exception occurs. This means that if you take a hardware exception, call RaiseException yourself, or call longjmp none of your C++ destructors between the point of exception and the handler will be invoked. I've talked about why this is a good idea, but I'll sum it up with this: If that scenario seems bad to you, then you should be compiling your code with /EHa.

Anyway, back to the issue: Say I'm writing a 'personality routine' which will be inovked by the OS when an exception occurs. If you're writing the kind that requires that your handler initiates the second phase of unwind, you need to call RtlUnwindEx. The documentation, which is arguably bad (it's little more that a function declaration), indicates that the EXCEPTION_RECORD structure to pass in is optional. And that's true: the functions on the stack will still be unwound. But the personality routines for those functions might want to actually know that they're being invoked due to an exception, and not for something like a longjmp. So, if you have an exception record that could be passed to the RtlUnwindEx function, you should. If you don't, another personality routine might assume that there's not an exception to examine, and might decide to do something like NOT invoke the destructors for the object on the stack.

BTW - this bug exists only on x86, and only when you're crossing a managed code -> native code boundary, in particularly weird scenarios. And I hope it's getting fixed :-)

-Kev

Bug in x86 inline assembly to watch out for

Kevin Frei — Tue, 17 Oct 2006 23:53:00 GMT

Imagine this very lame code:

int main() {}

void BugAsm() 
{
   __asm {
        MOV     [ESP+12],OFFSET main
   }
}

void(*BugAsmPt)()=&BugAsm; // this is just to make sure the function is not removed by /OPT:REF

Now imagine your significantly less lame code doing something similar.
Now imagine that the compiler crashes with a bizzare message about "x86\code.c" something or other.

Well, you can fix this problem by changing the assembly code to this:

mov DWORD PTR[esp+12], OFFSET main

Another unfixed bug, worked around :-|

-Kev

ML64 bug to watch out for

Kevin Frei — Thu, 20 Jul 2006 23:45:00 GMT

If you're porting your application to x64, and you use much in the way of __asm in your x86 code, you're likely to start looking at ml64 - the 64 bit version of Masm. The reason you're likely to do this is that the x64 compiler doesn't support __asm blocks in C code. So you can either use the compiler intrinsic functions [and there are a lot of 'em, and they're all documented relatively well], or you have to use ml64. For folks that aren't new to Masm, you're also likely to try to use some of the nifty little time-saver features of Masm to automatically generate prologue's and epilogues for your functions. For ML64, DO NOT DO THIS!
Here's an example:
.DATA
.CODE
testfunc PROC uses rbx
xor rbx, rbx
ret
testfunc ENDP
END
There are 2 problems with the code that ML64 generates. #1: There is no .xdata of any sort. No unwind directives are emitted, despite the fact that you're allocating stack, and saving a nonvolatile register. #2: The epilogue is invalid - it uses the 'leave' instruction, which is ineffecient, but also just plain illegal in an x64 function epilogue. The stack unwind routines will not properly recognize the instruction sequence as an epilogue, so the debugger and the EH routines will all fail [the EH routines will just terminate your process if an exception occurs while testfunc is on the stack].

BTW - Here's the link to the customer bug. It came in about 3 months too soon for serious consideration for VC8, so we punted it to the next version, but now it's pushed out until we get some more resources for investment in MASM.