8a4a2a
From 72f541fd317321fbd0395dcaa77830aa8b5d35b6 Mon Sep 17 00:00:00 2001
8a4a2a
From: Thierry Bordaz <tbordaz@redhat.com>
8a4a2a
Date: Wed, 15 Nov 2017 16:38:28 +0100
8a4a2a
Subject: [PATCH] Ticket 49410 - opened connection can remain no longer poll,
8a4a2a
 like hanging
8a4a2a
8a4a2a
Bug Description:
8a4a2a
    Some opened connection are no longer poll.
8a4a2a
    Those connections has 'gettingber' toggle set although there is
8a4a2a
    no more worker thread reading it.
8a4a2a
    The reason they have gettingber set is that the last
8a4a2a
    operation had 'persistent search' flag. With such flag
8a4a2a
    gettingber is not reset.
8a4a2a
    persistent flag is set even when no persistent search/sync_repl
8a4a2a
    was received on the connection.
8a4a2a
    The problem is that the flag is tested on the wrong operation.
8a4a2a
    The tested operation can be
8a4a2a
        - the first operation when the connection entered in turbo mode
8a4a2a
        - the previous operation if several ops PDUs were read on the network
8a4a2a
        - accessing random memory
8a4a2a
8a4a2a
    In theory testing the flag can lead to sigsev even
8a4a2a
    if it never crash
8a4a2a
8a4a2a
Fix Description:
8a4a2a
    The fix is to use the operation that is in the pblock
8a4a2a
    In such case pb_op is no longer used, so we can get rid of it.
8a4a2a
    In addition make pb_conn a local variable where it is used
8a4a2a
8a4a2a
https://pagure.io/389-ds-base/issue/49410
8a4a2a
8a4a2a
Reviewed by: Ludwig Krispenz, Mark Reynolds
8a4a2a
8a4a2a
Platforms tested: F26
8a4a2a
8a4a2a
Flag Day: no
8a4a2a
8a4a2a
Doc impact: no
8a4a2a
---
8a4a2a
 ldap/servers/slapd/connection.c | 2 ++
8a4a2a
 1 file changed, 2 insertions(+)
8a4a2a
8a4a2a
diff --git a/ldap/servers/slapd/connection.c b/ldap/servers/slapd/connection.c
8a4a2a
index 359b59a4d..c00c88578 100644
8a4a2a
--- a/ldap/servers/slapd/connection.c
8a4a2a
+++ b/ldap/servers/slapd/connection.c
8a4a2a
@@ -1540,6 +1540,8 @@ connection_threadmain()
8a4a2a
 		}
8a4a2a
 
8a4a2a
 		if (!thread_turbo_flag && !more_data) {
8a4a2a
+			Connection *pb_conn = NULL;
8a4a2a
+
8a4a2a
 			/* If more data is left from the previous connection_read_operation,
8a4a2a
 			   we should finish the op now.  Client might be thinking it's
8a4a2a
 			   done sending the request and wait for the response forever.
8a4a2a
-- 
8a4a2a
2.13.6
8a4a2a