Re: 3.0 assertion in comm.cc:572

Adrian Chadd wrote:
> 2009/5/11 Amos Jeffries <squid3_at_treenet.co.nz>:
>> We have one user with a fairly serious production machine hitting this
>> assertion.
>> It's an attempted comm_read of closed FD after reconfigure.
>>
>> Nasty, but I think the asserts can be converted to a nop return. Does anyone
>> know of a subsystem that would fail badly after a failed read with all its
>> sockets and networking closed anyway?
>
> That will bite you later on if/when you wanted to move to support
> Windows overlapped IO / POSIX AIO style kernel async IO on network
> sockets. You don't want read's scheduled on FDs that are closed; nor
> do you want the FD closed during the execution of the read.
>
> Figure out what is scheduling a read / what is scheduling the
> completion incorrectly and fix the bug.
>

Problem appears to be unshutdown helpers read events being triggered
after comm shutdown.

Looks like we will have to add another async step into the shutdown then
for a proper closure of the helpers.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
   Current Beta Squid 3.1.0.7