C
Chronologic
I got this error from my compiler with a little test class I was
playing with one afternoon.
It's not production code or anything, but it's small and I looked it
over pretty carefully and couldn't find anything wrong.
I am just playing around with winsock at a low level and I want it to
be cross platform so I'm not using any wrappers or anything and there
IS the possibility that I have a buffer overrun happening, though I
don't think so. I am positive that my code in it's current test state
is vulnerable to an overrun but I'm also pretty sure that none of my
test inputs would ever actually cause an overrun.
Reading a historical post on the subject lead me to what should cause
the error, basically having buffers around variables get messed up.
Each variable should have a 0xcccccccc buffer around it that shouldn't
get messed with. Waste of space but nice to help you catch MOST
problems of stack corruption. I wonder if it only allocates these
buffers in debug mode? Probably.
In my case, it looked like nothing had disturbed the stack around
port, by the time the program was exiting and the stack was clearing
the buffers looked perfectly intact.
Here is what I had:
left buffer port right buffer
cc cc cc cc cc 08 00 00 cc cc cc cc
Port's value is 2252 in decimal, which converted to hex and byte
flipped becomes
cc 08 00 00. I next Tested with port = 3000 which is b8 0b 00 00 and
it did the same thing.
I had thought maybe the presence of another byte with cc in it might
have been the problem (unlikely). But it wasn't.
The type of port was "unsigned short". So next I changed it to long
and ignored the compiler's auto cast warning
After doing that the error no longer shows up.
I realized at that point that I was using scanf with a %d specifier to
populate an usigned short variable. Now I don't generally use scanf
at all anymore but I was just playing around and didn't want to get
complex. scanf will copy a number just fine using %d but it
interprets it as an int, which is four bytes. an unsigned short on my
system is 2 bytes. Bingo. Those zeros should be cc's.
So if anyone else is getting this I can confirm that VC 7 seems to be
doing the right thing and you should look closely at a memory dump
around the variables that it says have stack corruption near them.
Quite handy actually.
--Chronologic
playing with one afternoon.
It's not production code or anything, but it's small and I looked it
over pretty carefully and couldn't find anything wrong.
I am just playing around with winsock at a low level and I want it to
be cross platform so I'm not using any wrappers or anything and there
IS the possibility that I have a buffer overrun happening, though I
don't think so. I am positive that my code in it's current test state
is vulnerable to an overrun but I'm also pretty sure that none of my
test inputs would ever actually cause an overrun.
Reading a historical post on the subject lead me to what should cause
the error, basically having buffers around variables get messed up.
Each variable should have a 0xcccccccc buffer around it that shouldn't
get messed with. Waste of space but nice to help you catch MOST
problems of stack corruption. I wonder if it only allocates these
buffers in debug mode? Probably.
In my case, it looked like nothing had disturbed the stack around
port, by the time the program was exiting and the stack was clearing
the buffers looked perfectly intact.
Here is what I had:
left buffer port right buffer
cc cc cc cc cc 08 00 00 cc cc cc cc
Port's value is 2252 in decimal, which converted to hex and byte
flipped becomes
cc 08 00 00. I next Tested with port = 3000 which is b8 0b 00 00 and
it did the same thing.
I had thought maybe the presence of another byte with cc in it might
have been the problem (unlikely). But it wasn't.
The type of port was "unsigned short". So next I changed it to long
and ignored the compiler's auto cast warning
After doing that the error no longer shows up.
I realized at that point that I was using scanf with a %d specifier to
populate an usigned short variable. Now I don't generally use scanf
at all anymore but I was just playing around and didn't want to get
complex. scanf will copy a number just fine using %d but it
interprets it as an int, which is four bytes. an unsigned short on my
system is 2 bytes. Bingo. Those zeros should be cc's.
So if anyone else is getting this I can confirm that VC 7 seems to be
doing the right thing and you should look closely at a memory dump
around the variables that it says have stack corruption near them.
Quite handy actually.
--Chronologic