How can I go about debugging SIGSEV in gdb?

[CptanPanic]

I am building previously working code, but I am getting a seg fault and I can't figure out what went wrong. gdb catches the error, but it doesn't point to an obvious cause. The source line it shows is a function name, so it doesn't even get into the function. If I look at the dissasembly of the instruction it is still setting up the stack, so maybe the stack is messed up. So how should I go about debugging this? This is in QNX 6.2, console gdb only.

Code: Select all

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56
56      tcMatrix tcMatrix::operator*(float64 anMultiplier)

0x816b820 <__ml>:       push   %ebp
0x816b821 <__ml+1>:     mov    %esp,%ebp
0x816b823 <__ml+3>:     sub    $0x13ac,%esp
0x816b829 <__ml+9>:     push   %edi
0x816b82a <__ml+10>:    push   %esi
0x816b82b <__ml+11>:    push   %ebx

[mario]

If a push is caushing the crash then it`s most probably a stack overflow. Make sure you program isn`t using too much stack ( C++ can be nasty when it creates temporary object like on you ). If it is ok use the -N option to increase stack size (link time)

[davidk2]

Check bounds on arrays. This is the most common cause of stack corruption.

You'll probably find that you are writing to and index greater than the length of the array somewhere.

Also check any pointers that you have allocated enough memory for what you are copying into that part of memory.

David

[CptanPanic]

Thanks I was able to fix it by creating the thread with a larger stack size.

[mario]

davidk2: it`s not writing to an index greater then lenght of array because this is never acheive with a push intruction. Push only operation on the stack, (at least in C/C++

[davidk2]

What I meant was. If you write to a piece of memory that you have not allocated to then anything could be in that part of memory including the stack.

http://en.wikipedia.org/wiki/Stack_buffer_overflow

I think it could still be stack corruption rather than running out of memory (i've seen this before):

#define BUFF_SIZE 1000
...

BYTE txbuffer[BUFF_SIZE];
....
for(i=0;i<2048;i++)
{
txbuffer[i] =0;
}

[mario]

The code you posted might create a sigsegv, you have to hit the guard page for that, so the stack pointer has to be 1K below the limit, for it to crash. Still your code would NOT crash on a push instruction, it would crash on a mov instruction. Increasing stack size may prevent the crash but the program would still be buggy.

A SIGSEGV on a push instruction means you are trying to grow the stack beyond it`s size. The code you post is not growing the stack beyound its size.

[davidk2]

The code you posted might create a sigsegv, you have to hit the guard page for that, so the stack pointer has to be 1K below the limit, for it to crash. Still your code would NOT crash on a push instruction, it would crash on a mov instruction. Increasing stack size may prevent the crash but the program would still be buggy.

A SIGSEGV on a push instruction means you are trying to grow the stack beyond it`s size. The code you post is not growing the stack beyound its size.

I agree on this. I was confused with your original response. I have tried this out and you are quiet correct.

The code I posted must have been hitting the guard page.

David