Subject: Re: squid now reveals a new kernel problem.
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Charles M. Hannum <firstname.lastname@example.org>
Date: 10/28/1999 19:10:18
email@example.com (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
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