Why does ~DeferredReadManager read?

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 31 Oct 2008 10:10:28 -0600

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

Thank you,

Alex.
Received on Fri Oct 31 2008 - 16:10:44 MDT

This archive was generated by hypermail 2.2.0 : Sat Nov 01 2008 - 12:00:06 MDT