Subject: Re: squid now reveals a new kernel problem.
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Charles M. Hannum <>
List: tech-kern
Date: 10/28/1999 19:10:18 (Greg A. Woods) writes:

> [ 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().

That was a typo.  The point stands; you *must* remove the pointer from
the file descriptor table, which you're not doing.

> 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.

Note that sys_socket(), sys_socketpair(), sys_pipe(), sys_open() and
sys_fhopen() -- which are all the routines that use ffree() -- do this

In short, both your change and Darren's are clearly