Adrian Chadd wrote:
2009/5/11 Amos Jeffries <[email protected]>:
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
