I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation error. (Not as infrequent as some bugs that
have been discussed here in the past, but maybe once in an overnight
run of the program when it was configured to aggressively exercise the
section that the bug was in.) It was easy enough to trap the error
(using compiler features that are beyond the scope of this newsgroup)
and retry, and the retry would always work, but the glitch was still
Annoying to me and one other correctness pedant I work with.
Turns out that the offending code looked something like this:
for(i=0;i<num;i ++)
if(check(array[i]))
break;
if(check(array[i]))
continue;
array was a pointer to a malloc'd array of num structs; check() was
an expression that compared a member of the struct to another value.
(If the values matched, we didn't need to do anything more in the
next-outer loop.)
But if the for loop failed to exit abnormally, the check after it exited
would attempt to read the value just past the end of the malloc'd space.
My best guess about what the problem was is that normally this wasn't a
problem, since the bogus value was Highly Unlikely to match what it was
being checked against and the program was allowed to read that memory
(and didn't try to write to it), but occasionally the mallocd space would
be just at the high end of the process's memory space and attempting to
read a few bytes past it would access memory that the process didn't own,
and the OS would trap it.
This may be useful the next time somebody comes around and tries to
claim that "It works on my system" or something similar.
Comments?
dave
--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
Welcome to comp.lang.c. People here are picky. That's good - it means you can
(generally) trust the answers you get - or at least, you can trust the answer
that emerges after a couple of days of bickering. --Richard Heathfield in CLC
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation error. (Not as infrequent as some bugs that
have been discussed here in the past, but maybe once in an overnight
run of the program when it was configured to aggressively exercise the
section that the bug was in.) It was easy enough to trap the error
(using compiler features that are beyond the scope of this newsgroup)
and retry, and the retry would always work, but the glitch was still
Annoying to me and one other correctness pedant I work with.
Turns out that the offending code looked something like this:
for(i=0;i<num;i ++)
if(check(array[i]))
break;
if(check(array[i]))
continue;
array was a pointer to a malloc'd array of num structs; check() was
an expression that compared a member of the struct to another value.
(If the values matched, we didn't need to do anything more in the
next-outer loop.)
But if the for loop failed to exit abnormally, the check after it exited
would attempt to read the value just past the end of the malloc'd space.
My best guess about what the problem was is that normally this wasn't a
problem, since the bogus value was Highly Unlikely to match what it was
being checked against and the program was allowed to read that memory
(and didn't try to write to it), but occasionally the mallocd space would
be just at the high end of the process's memory space and attempting to
read a few bytes past it would access memory that the process didn't own,
and the OS would trap it.
This may be useful the next time somebody comes around and tries to
claim that "It works on my system" or something similar.
Comments?
dave
--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
Welcome to comp.lang.c. People here are picky. That's good - it means you can
(generally) trust the answers you get - or at least, you can trust the answer
that emerges after a couple of days of bickering. --Richard Heathfield in CLC
Comment