Re: why does assert(0) corrupt the stack trace?

> On Nov 5, 2017, at 12:05 PM, 慕冬亮 <[email protected]> wrote:
> 
> If I compile the program with "-O0", this problem may be solved. Yes?

Often with “-O0” (dash OH zero, turning the optimizer off) helps this is the most direct route to try to determine what went wrong.

However - it depends on what went wrong, for example if your application has a buffer overflow on the stack, and that buffer overflow corrupted the stack - or other memory was corrupted the stack back trace might as a result be corrupt

Or - the problem might change/move when you disable the optimizer the code changes, the number of registers allocated per function changes, etc ... 

That said, the most direct and most common thing to do is to disable the optimizer and try again.

If you get desperate and the above does not help you might try unwinding the stack by hand - it takes a while and often you can do what the compiler & debugger cannot do.

This approach trys to understand where the application was, and what it was doing when the crash occurred - sometimes you can inspect memory at or near the stack, and manually unwind the stack by inspecting various values stored on the stack.

For example, on a 32bit machine - dump the stack memory near the stack pointer (ie: +/- 512 bytes) as 32bit values - then look at each value and see if they align with addresses within your application where subroutine calls occur.  (Ie:  Use “objdump -d MYAPP” to get a disassembly listing of your app)

It is painful but sometimes it is the only way.

-Duane.