Strange AccessViolation in GetRawStackTrace

[zwanderer]

I'm running FullDebugMode on a large application and sometimes it raises some access violations inside FullDebugMode DLL, on GetRawStackTrace specifically. The exception seems to be handled since program execution doesn't get affected at all, but I'd rather not happen when debugging our application since other developers would freak out (we're mandating everyone to check for memory leaks before posting code).

I debugged the DLL and the access violation is happening on IsValidCallSite at line 286:

if PByteArray(LCallAddress)[3] = $E8 then

This exception happens when AReturnAddress points to an address below 4MB ($3fffff). I noticed at the beginning of the function that it only tests addresses above 65KB and below 4GB, so I changed the first line to

if (AReturnAddress > $3fffff) and (AReturnAddress <= $ffffffff) then

And the access violations stop happening, but I'm not sure if this is a valid change, what kind of side effects it can introduce, if my application has a stack corruption, or if those access violations weren't supposed to happen at all just by reading an address below 4MB.

I'm looking for pointers on how to gather more info about this issue.

With regards,

[pleriche]

Hi,

With "raw" traces enabled the stack tracer has to test addresses it encounters on the stack to determine whether they are actual return addresses or not. As I explained in my comments to issue #49, sometimes it steps into an unmapped area of the address space which causes an A/V. This A/V is handled, but it can be scary if you encounter it when you run the application under a debugger. Unfortunately, it's hard to avoid this from happening without slowing down the raw stack trace process significantly.

If you want to avoid this you can disable raw stack traces, but then you would have to enable the generation of stack frames in the compiler options (at least in your debug build) otherwise the stack traces will lose a lot of detail.

Best regards,
Pierre

[zwanderer]

Thanks, I changed to Frame based stack trace and it worked. I noticed it already does that when in Win64, that's why I only noted when I changed to Win32.