Re: Segmentation fault in FwdState::serverClosed

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.
Received on Thu May 08 2014 - 15:34:15 MDT