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