How do I find a stack overflow problem in linux?

Question

I am compiling my application with a third party lib and there seems to be some weird behaviour that suggests a stack overflow issue (this is just a guess).

But when I add a print statement after the line that's crashing the application runs fine. If I remove the print statement (a simple cout << "print something" << endl; statement) the application crashes on a

0x00007f48f2027276 in free () from /lib64/libc.so.6

I tried adding the following char array in place of the print statement and this stopped the crash as well, I then attempted to print the contents of the char array:

char ben[8000] = {0};
memset(&ben, 0, sizeof (ben));

for (int y = 0; y < 8000; ++y)
{
if (ben[y] != 0)
  PRINT ("CHAR[%d]=%d", y, ben[y]);
}

to see if anything in the array gets corrupted, but this approach did not work. So I was wondering if there are better ways to detect whether or not this is a stack overflow problem?

I recompiled the application with -fstack-protector-all (both the lib and my code) and this did not turn up anything. I also tried valgrind and it did not give me anything that looked suspicious.

It seems like it's crashing because I'm trying to free an invalid pointer, but I have no idea why the pointer is invalid since it's freeing a local variable (i.e. when it falls out of scope). The pointer is getting corrupted for a reason, but it's a bit like looking for a needle in a haystack. Are there any good techniques to try and converge on this type of problem? Thanks a lot!

Answer 1

You should give valgrind's Memcheck tool a go. It's a memory debugger that will let you know if you access memory you shouldn't (case of stack overflow, double-free, access to freed pointers, array overflow, ...)

Answer 2

Compiling with -fstack-protector-all will have the program let you know if the stack is being smashed.

Answer 3

That smells like a pointer corruption problem, not a stack overflow. If the application is large, try inserting return at the top of major functions to limit the amount of code executing.

Once the range of suspect code is constrained, carefully desk check pointer management. Especially be sure that any pointer sent to free() or a destructor hasn't been trashed beforehand.

Answer 4

If memcheck/valgrind don't turn up anything, you can always fire up gdb and look at the assembly.

Some other things to check for are uninitialized variables, these have been known to cause unexpected errors. Also use -Wall if you aren't already, it may turn something up.

It really does sound like a bad pointer problem. See this site for some good tips.