[EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: >> Hallvard B Furuseth wrote: >>> test036-meta-concurrency just crashed with fresh HEAD code. >>> I suppose that's the same as this ITS. >> Looks like. However, now I thought my FIXME were little more than a >> precaution. In fact, right now the only places where c_struct_state can >> be modified are protected by a mutex on connections_mutex; this should >> prevent changing the state of a connection during a connection_next() >> call. Do you see a thread waiting on >> ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or >> connection.c:514? If that's the case, we probably need to move >> c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able >> to safely assert in connection_next(). Is it worth? > > That should not be necessary. c_struct_state is supposed to be protected by > connections_mutex, while c_conn_state is supposed to be protected by > c->c_mutex. As already described in the comments at the top of the file.
What seesm to happen is that c_conn_state is changed, then connections_mutex prevents from changing c_struct_state. As a consequence, connection_next() treats a connection structure based on its c_struct_state, which is now correctly protected, but then asserts on its c_conn_state, which has already been modified. So we are asserting on the state of a connection that is being modified, and is by design in a temporarily inconsistent state. Now things should be safe, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: [EMAIL PROTECTED] -----------------------------------
