You are not logged in.
Pages: 1
I doubt it's a pure stack overflow of that sort (ie: just using too much stack space)... Much more likely is dynamic heap corruption... Though, I'm not sure why valgrind wouldn't spot it for you... It's always been great at catching such things for me... Perhaps it is stack corruption of some sort, such as overflowing a stack buffer and trashing other important stuff also on the stack (like function return addresses)... It's hard to say without seeing more code...
However, just from the 3 lines you posted, I don't like the look of the third one... A scanf("%s") is unbounded, so could easily overflow your buffer there... You'd be far better off using something like fgets() or getline() for input...
Offline
From the lines posted, I would guess that 'buffer' isn't always NUL terminated.
(or line terminated, for that matter.) Make sure the receiver always terminates
the buffer with a NUL before processing the data.
Stack size you can see in /proc/$PID/smaps, for instance. So you could check
that when it's hanging in gdb after a crash.
Took me forever to find out that X crashed with no error messages because
it used more stack than I allowed with ulimit -s.
Offline
I got confused by that scanf, thougth 'buffer' was the input instead of stdin.
That's indeed a strange way of using scanf(), I'd do what Rob suggests and
use something better fitting that's also not unbound.
What I meant is the buffer where the UDP packet is received into. But if the
UDP data aren't strings then never mind about NUL termination.
Offline
char *stackstart = NULL;
int main(){
int someotherlocalvar;
char bottom_of_stack;
stackstart = (char*)&bottom_of_stack;
...Last edited by thinking (2011-08-31 03:26 PM)
Offline
Pages: 1