[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts



This is a multi-part message in MIME format.
--------------090602010509010401080002
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I saw that the master is lost some changes of the my original patch 
(that was early attached to ITS).

Please see attached diff.
I think it is a race condition around si_cookieState inside for-loop.

--------------090602010509010401080002
Content-Type: text/x-patch;
 name="its#7968-lost.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="its#7968-lost.patch"

diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c
--- a/servers/slapd/syncrepl.c
+++ b/servers/slapd/syncrepl.c
@@ -958,15 +958,17 @@ do_syncrep2(
 								ldap_pvt_thread_yield();
 						}
 
+						ldap_pvt_thread_mutex_lock( &si->si_cookieState->cs_mutex );
 						for ( i =0; i<si->si_cookieState->cs_pnum; i++ ) {
 							if ( sid < si->si_cookieState->cs_psids[i] )
 								break;
 							if ( si->si_cookieState->cs_psids[i] == sid ) {
 								if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_pvals[i] ) <= 0 ) {
-									ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex );
 									bdn.bv_val[bdn.bv_len] = '\0';
 									Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN pending, ignoring %s (%s)\n",
 										si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val );
+									ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex );
+									ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_pmutex );
 									ldap_controls_free( rctrls );
 									rc = 0;
 									goto done;
@@ -983,6 +985,7 @@ do_syncrep2(
 								(struct sync_cookie *)&si->si_cookieState->cs_pvals,
 								i, sid, syncCookie.ctxcsn );
 						}
+						ldap_pvt_thread_mutex_unlock( &si->si_cookieState->cs_mutex );
 						assert( punlock < 0 );
 						punlock = i;
 					} else if (si->si_too_old) {

--------------090602010509010401080002--