Re: Is this a bug in libc6?
On 12 Apr 1998, Gregory S. Stark wrote:
> > Yes, it would be quite difficult to do efficently. There's no good way
> > to tell that the pointer you're passing is _really_ a FILE* pointer.
> > Once it's closed, the pointer's value is meaningless.
>
> One cheap solution which will usually work is to put a magic number at the
> head of the FILE* structure and clear it when the close is done (before
> the free). This doesn't work 100% of the time but in practice would it
> would work.
Some malloc implementations (see electric fence) segfault when you even
attempt to read a dead pointer. But the real problem is something like
this:
FILE *f1, *f2;
f1 = fopen("existing_file", "r");
fclose(f1);
f2 = fopen("existing_file", "r");
fclose(f1);
fread(buffer, size, f2); /* oops!! */
It's quite possible (likely) that the second fopen() allocated the same
memory as the first, because the first fclose() released it and the second
fopen() wants a block of the same size. Thus, the second fclose(f1), which
you would like to be harmless, isn't. The magic number doesn't help here.
It would make things crash less in the general case, but that's not
necessarily desirable.
> > Personally, as a programmer myself, I much prefer to work on a system
> > that gives up consistently when I do something wrong. That's what
> > segmentation faults are all about.
>
> Well, the problem with the current setup is really that it may or may not
> crash depending on what data is in the previously allocated structure.
> It's a source of randomness which is always bad for debugging.
On the up side, libc6 seems to crash more :) I think electric fence would
make it crash consistently. That's not to say that magic numbers wouldn't
be a useful way to make it die _more_ consistently.
I think the best way to develop software is on a paranoid system; the best
way to run it is on a very relaxed system. For example, Solaris doesn't
seem to die with this bug; Linux does. If hylafax had been written on
Linux, this bug would have been found sooner and the program would have run
okay on _both_.
(Note that this isn't a snub at Solaris: I have a reverse example related
to curses/ncurses if anyone cares.)
If we could have an ultra-paranoid library for development, and an
ultra-relaxed library for an operating environment, maybe we'd be better
off. For now, I just do all my testing with electric fence.
Have fun,
Avery
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: