Hi,
recently i have experienced having corrupted stack frames.
Its multi threaded environment..
My process got crashed due to stack overflow.
You have memset call where the size you are not initialized .
example:
int n;
char buf[100];
memset(buf, 0, n) ;
(gdb) bt
#0 0x0183e4c8 in byte32sse2 ()
#1 0xb1036f68 in ?? ()
#2 0x00001b98 in ?? ()
#3 0x0183ba51 in _intel_fast_memset ()
#4 0xb1036e10 in ?? ()
#5 0x00000000 in ?? ()
(gdb)
this is how the intel memset thread stack trace shows.
It would be difficult to find out, in a process where do you missed to initialize the size n.
The best approach.
Run gdb check for
esp -- top of stack pointer.
use objectdump -sSLdx <process binary>
save the output to a file
run gdb check for esp
x/32gwa $esp
it would possible give the some traces.
go over the address in the esp
esp is the top of the stack frame.
search the address in the output of objectdump utility. You shall get some clue on Root Caused.
recently i have experienced having corrupted stack frames.
Its multi threaded environment..
My process got crashed due to stack overflow.
You have memset call where the size you are not initialized .
example:
int n;
char buf[100];
memset(buf, 0, n) ;
(gdb) bt
#0 0x0183e4c8 in byte32sse2 ()
#1 0xb1036f68 in ?? ()
#2 0x00001b98 in ?? ()
#3 0x0183ba51 in _intel_fast_memset ()
#4 0xb1036e10 in ?? ()
#5 0x00000000 in ?? ()
(gdb)
this is how the intel memset thread stack trace shows.
It would be difficult to find out, in a process where do you missed to initialize the size n.
The best approach.
Run gdb check for
esp -- top of stack pointer.
use objectdump -sSLdx <process binary>
save the output to a file
run gdb check for esp
x/32gwa $esp
it would possible give the some traces.
go over the address in the esp
esp is the top of the stack frame.
search the address in the output of objectdump utility. You shall get some clue on Root Caused.
No comments:
Post a Comment