[ On , October 28, 1999 at 16:44:16 (-0400), Charles M. Hannum wrote: ]
> Subject: Re: squid now reveals a new kernel problem.
>
> I don't see what's surprising about this.  fdalloc() put the struct
> file (`fp') into the process's file descriptor table, but your ffree()
> call did not remove it.  Any future operation on that file descriptor
> -- including cleanup during process exit -- will thus walk a stale
> pointer.
> 
> You should have used fdrelease() instead.

There's no call to fdalloc() -- only falloc().  Indeed fdrelease() calls
closef() which was the source of the original problem.  Seems
fdrelease() would be wrong too, unless there's something about it that I
don't yet understand.

> I'm quite disturbed that such a change was made without actually
> testing it prior to commit.

I presume Darren had done some testing of his original closef() change,
but my testing proved that something was wrong with his fix under some
circumstances.  Darren's fix was of course very much in line with
similar changes to the other *BSDs.  However in examining what appeared
to me to be similar code in other routines in uipc_syscalls.c it seemed
to me that ffree() was the correct call, not closef().

Indeed my idea to mimic the other routines and use ffree() survived
testing twice as long in a relatively heavy production environment
without even exhibiting any of the previous symptoms of the problem I
was trying to solve in the first place, and only failed in a new
scenario.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>