CODEWITHSUNDEEP
c++android-ndkgdb
Equidamoid
Equidamoid

Reputation: 1472

How to prevent stack corruption?

I'm trying to debug segfault in native app for android. 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 a place where the stack was corrupted?

UPD: The function mentioned takes references:

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

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

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

Upvotes: 5

Views: 3513

Answers (3)

Equidamoid
Equidamoid

Reputation: 1472

Solved this problem only by stepping line-by-line from the beginning of suspicious code and looknig for the moment when the stack gets corrupted.(It was ugly pointer arithmetic with two-dimensional arrays.)

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

Upvotes: 0

SoapBox
SoapBox

Reputation: 20609

Compiling with --fstack-protector-all will cause your program to abort (with signal SIGABRT) when it returns from a function that corrupts the stack, if that corruption includes the area of the stack around the return address.

Stack-protector-all isn't a great debugging tool, but it is easy to try and sometimes does catch problems like this one. Though it will not point you to which line caused the problem, it will at least narrow it down to a single function. Once you have that information, you can step through it in GDB in order to pinpoint the line in question.

Upvotes: 2

Potatoswatter
Potatoswatter

Reputation: 137860

We don't have much information to go by! There is no general rule to avoid memory corruption except to be careful with addressing.

But it looks to me like you overflowed an array of floats, because the bogus address 0xbfcc6744 equates to a reasonable float value -1.597 which is in line with the other values reported by GDB.

Overwriting the return address caused execution to jump to that value, so look specifically at the caller of the function WWMath::unProject, whose locals precede its return address, to find the offending buffer. (And now we have it, near.)

Upvotes: 5

Related Questions