How to prevent stack damage?

Question

I am trying to debug segfault in a native android application. GDB shows the following:

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5200] 0xbfcc6744 in ?? () (gdb) bt #0 0xbfcc6744 in ?? () #1 0x5cfb5458 in WWMath::unProject (x=2.1136094475592566, y=472.2994384765625, z=0, mvpMatrix=@0x0 , viewport=@0x0 , result=@0x0 ) at jni/src/core/util/WWMath.cpp:118 #2 0x00000000 in ?? () 

Is it possible to get a good stack? Or find the place where the stack was damaged?

UPD: The mentioned function contains links:

 bool WWMath::unProject(double x, double y, double z, const Matrix &mvpMatrix, const Rect& viewport, Vec4& result) 

and a reference to a simple local variable is passed as the last argument:

 Vec4 far, near; if (!unProject(x, y, 0, tMvp, viewport, near)) 

Answer 1

We don’t have much information! There is no general rule to avoid memory corruption other than being careful with addressing.

But it seems to me that you have overflowed the float s array, because the dummy address 0xbfcc6744 equates to a reasonable float value of -1.597 , which corresponds to other values ​​reported by GDB.

The completion of the return address led to the execution moving to this value, so look at the caller of the WWMath::unProject , whose locators precede the return address to find the offending buffer. (And now we have it, near .)

Answer 2

Compiling with --fstack-protector-all will cause your program to interrupt (with a SIGABRT signal) when it returns from a function that damages the stack if this damage includes the stack area around the return address.

The Stack-protector is not a great debugging tool, but it's easy to try and sometimes catch problems like this. Although it will not indicate which line caused the problem, it will at least reduce it to one function. Once you get this information, you can go through it in GDB to pinpoint this line.

Answer 3

This problem is solved only by a step-by-step step-by-step start with a suspicious code and viewing at the moment when the stack is damaged. (It was ugly pointer arithmetic with two-dimensional arrays.)

And it seems that there is another way: try to paste everything into a heap and hope that the incorrect operation will cause segfault.