Does anyone have any thoughts on ITS#5835?
The server keeps hitting the assert in connection.c:
static void connection_close( Connection *c ) { ber_socket_t sd = AC_SOCKET_INVALID;
assert( connections != NULL ); assert( c != NULL );
/* ITS#4667 we may have gotten here twice */ if ( c->c_conn_state == SLAP_C_INVALID ) return;
assert( c->c_struct_state == SLAP_C_USED ); --> assert( c->c_conn_state == SLAP_C_CLOSING );
Which was called by connections_timeout_idle in connection.c:
if( difftime( c->c_activitytime+global_idletimeout, now) < 0 ) { /* close it */ connection_closing( c, "idletimeout" ); --> connection_close( c ); i++;
With the modified debug logging Howard checked in, I see the following steps taking place:
Dec 2 03:06:05 ldap slapd[8292]: connection_closing: readying conn=3049 sd=28 for close
so we know it made it into connection_closing.
Then we see:
Dec 2 03:06:05 ldap slapd[8292]: connection_resched: attempting closing conn=3049 sd=28
which means it made it to connection_resched, which calls connection_close:
Debug( LDAP_DEBUG_CONNS, "connection_resched: " "attempting closing conn=%lu sd=%d\n", conn->c_connid, sd, 0 ); connection_close( conn );
Doesn't this directly conflict with line 242 above, which also calls connection_close on the connection?
I also see this comment in the connection_closing code:
/* ITS#4667 this may allow another thread to drop into * connection_resched / connection_close before we * finish, but that's OK. */
I'm honestly not sure this is really "OK". The only place I see connection_resched called is from connection_operation, and I don't see exactly how I'ved ended up in there in this code path.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration