Re: Why does ~DeferredReadManager read?

Alex Rousskov wrote:
> -------- Forwarded Message --------
> http://www.squid-cache.org/bugs/show_bug.cgi?id=2505
>
>> 2008/10/31 14:37:24| assertion failed: comm.cc:350: "!fd_table[fd].closing()"
>>
>> #3 0x080f8ec9 in xassert (msg=0x821fd8d "!fd_table[fd].closing()",
>> file=0x821f7eb "comm.cc", line=187608064) at debug.cc:572
>> #4 0x0819be11 in comm_read (fd=16, buf=0xbc03000 "", size=4094,
>> callback=@0xbfbfe650) at fde.h:49
>> #5 0x081751af in StoreEntry::delayAwareRead (this=0x9db7200, fd=16,
>> buf=0xbc03000 "", len=4095, callback={p_ = 0xb038100}) at store.cc:256
>> #6 0x0817531e in StoreEntry::DeferReader (theContext=0x9db7200, aRead=@0x0) at
>> RefCount.h:123
>> #7 0x081955d6 in DeferredReadManager::kickARead (this=0xb8e2080,
>> aRead=@0xbfbfe6c0) at comm.cc:2592
>> #8 0x0819c206 in DeferredReadManager::flushReads (this=0xb8e2080) at
>> comm.cc:2581
>> #9 0x0819c322 in ~DeferredReadManager (this=0xb8e2080) at comm.cc:2502
>> #10 0x08156765 in ~MemObject (this=0xb8e2000) at MemObject.cc:128
>> #11 0x0817443c in StoreEntry::destroyMemObject (this=0x9db7200) at store.cc:376
>> #12 0x08174946 in destroyStoreEntry (data=0x9db7204) at store.cc:389
>> #13 0x081766d0 in StoreEntry::release (this=0x9db7200) at store.cc:1282
>> #14 0x08176184 in StoreEntry::unlock (this=0x9db7200) at store.cc:498
>> #15 0x081835f1 in ~ServerStateData (this=0x110f9010, __vtt_parm=0x82086c4) at
>> Server.cc:76
>> #16 0x0811b902 in ~FtpStateData (this=0x110f9010) at RefCount.h:100
>> #17 0x081a3d6c in AsyncJob::callEnd (this=0x110fd11c) at ICAP/AsyncJob.cc:137
>> #18 0x081a41f1 in JobDialer::dial (this=0xafb2b1c, call=@0xafb2b00) at
>> ICAP/AsyncJob.cc:222
>> #19 0x0812804b in AsyncCallT<CommCbMemFunT<FtpStateData, CommCloseCbParams>
>>> ::fire (this=0x0) at AsyncCall.h:129
>> #20 0x080c60bd in AsyncCallQueue::fireNext (this=0x8484d90) at RefCount.h:72
>> #21 0x080c6229 in AsyncCallQueue::fire (this=0x8484d90) at AsyncCallQueue.cc:39
>> #22 0x0810c654 in EventLoop::dispatchCalls (this=0xbfbfeae0) at
>> EventLoop.cc:154
>> #23 0x0810c81e in EventLoop::runOnce (this=0xbfbfeae0) at EventLoop.cc:119
>> #24 0x0810c959 in EventLoop::run (this=0xbfbfeae0) at EventLoop.cc:95
>> #25 0x08152c42 in main (argc=-1077941536, argv=0xbfbfec80) at main.cc:1347
>
> Does anybody know why DeferredReadManager destructor forces deferred
> reads to read by calling flushReads? Besides leading to bugs, it seems
> kind of pointless to try to read if the object that guarded deferred
> reads is being destructed anyway.
>
> Should DeferredReadManager destructor cancel all pending operations
> instead?

I can't find it anymore, but seem to recall some of the other old FD
closing code had notes about linux nastiness extending TIME_WAIT for
sockets with data queued even after frormaly closed. Maybe its related
to that.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10
   Current Beta Squid 3.1.0.1