On 05/08/2014 07:21 AM, Amos Jeffries wrote: > This is a side effect of trunk rev.13388 (standby connections)
If this is something you can reproduce, please post/share an ALL,9 cache.log. > Something is still calling serverConn->close() directly instead of via > the FwdState::closeServer() method. This appears to be happening in at > least the FwdState methods connectTimeout(), dispatch() and > connectDone() error cases. > > > Program received signal SIGSEGV, Segmentation fault. > 0x082234fa in FwdState::serverClosed (this=0x8c46488, fd=-1) at > ../../src/FwdState.cc:625 > 625 fwdPconnPool->noteUses(fd_table[fd].pconn.uses); > (gdb) bt > #0 0x082234fa in FwdState::serverClosed (this=0x8c46488, fd=-1) at > ../../src/FwdState.cc:625 > #1 0x082230e6 in fwdServerClosedWrapper (params=...) at > ../../src/FwdState.cc:539 > #2 0x08373185 in CommCloseCbPtrFun::dial (this=0x8c3e12c) at > ../../src/CommCalls.cc:211 Do you know how a connection close callback (fwdServerClosedWrapper) can be called with fd set to -1? It feels like there is a shared Connection object that two different jobs are updating/closing independently, stepping on each other's toes. In theory, any connection owned by FwdState should not be in the standby pool but perhaps there is a bug in getting some standby connections disassociated from the standby code when they are passed to FwdState (e.g., a stale close handler that should have been removed)? A short-term, temporary workaround would be to skip the noteUses call when fd is not known, but there is clearly a bug somewhere that should be fixed. I will work on this if I can reproduce it or get the debugging logs. Cheers, Alex.
