RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1228823 - async simple paged results issue
Summary: async simple paged results issue
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 1133060 1230037
TreeView+ depends on / blocked
 
Reported: 2015-06-05 20:28 UTC by Noriko Hosoi
Modified: 2020-09-13 21:25 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.4.0-19.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1230037 (view as bug list)
Environment:
Last Closed: 2015-11-19 11:42:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1477 0 None None None 2020-09-13 21:22:54 UTC
Github 389ds 389-ds-base issues 1523 0 None None None 2020-09-13 21:25:38 UTC
Red Hat Product Errata RHBA-2015:2351 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2015-11-19 10:28:44 UTC

Description Noriko Hosoi 2015-06-05 20:28:11 UTC 
Ticket 48146 - async simple paged results issue
1. Description: When the last page of the single paged results is returned,
the search results structure is freed in the simple paged results code
(in op_shared_search).  The search results structure is stashed in the
simple paged results object across the pages.  The free and the clean up
of the stashed address should have been atomic, but it was not.

2. When the request is a simple paged results search,
   log pr index in the access log.
Sample access log for "getent netgroup <name>":
  [..] conn=23 op=521 SRCH base="cn=accounts,dc=testrelm,dc=test" scope=2 filter="(&(|(memberOf=ipaUniqueID=3036b6a0-ee18-11e4-b7dd-00215e2032c0,cn=ng,cn=alt,dc=testrelm,dc=test))(objectClass=ipaHost))" attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID"
  [..] conn=23 op=521 RESULT err=0 tag=101 nentries=200 etime=0 notes=P pr_idx=3

3. If multiple async simple paged results requests come in via one
connection simultaneously, the same slot in the paged results array in the
connection could be shared.  If one of them has to do paging, the search
request object stashed in the paged result array slot could be freed by the
other request if it has the shorter life cycle.

These 3 reqs use the same paged results array slot.
req0: <--------------><----x
page1           page2
req1: <----->
req2:              <------->
frees search result object of req0

Ticket 48192 - Individual abandoned simple paged results request has no chance to be cleaned up
1. When allocating a slot in simple paged results array stashed
in a connection in pagedresults_parse_control_value, a new code is added
to scan the array if the existing slot is timed out or not.  If it is, the
slot is released and a search results is released if it is attached.

Also, if a request is abandoned, instead of returning a valid cookie, it
changed to return an empty cookie to inform the client the request was not
successfully completed.
Comment 2 Noriko Hosoi 2015-06-05 23:01:12 UTC 
Justification: This bug was opened for rhel-7.2/rhel-7.1.z merging bugs filed against rhel-6.6 by strategic customers:

bz 1228402 - Individual abandoned simple paged results request has no chance to be cleaned up
bz 1218341 - ns-slapd crash related to paged results
Comment 5 Noriko Hosoi 2015-07-02 17:42:52 UTC 
Changing the status to ASSIGNED.
See 7.1.z bug: 1230037
Comment 6 Sankar Ramalingam 2015-07-14 16:30:47 UTC 
1.2. Verification steps from automated acceptance tests.

############## Result  for  backend test :   SIMPLEPAGED run
    SIMPLEPAGED run elapse time : 00:04:27
    SIMPLEPAGED run Tests PASS      : 100% (17/17)

############## Result  for  backend test :   filter run
    filter run elapse time : 00:06:31
    filter run Tests PASS      : 100% (273/273)

1.3. Running simplepaged C script given in comment #1

No crash observed. Also, no constant increase of pr_idx in the RESULT line.

I am proceeding with 1.1 step to run the CI tests.
Comment 7 Sankar Ramalingam 2015-07-14 16:32:54 UTC 
[root@qe-blade-12 slapd-testinst1]# rpm -qa |grep -i 389-ds-base
389-ds-base-1.3.4.0-5.el7.x86_64
389-ds-base-libs-1.3.4.0-5.el7.x86_64
389-ds-base-debuginfo-1.3.4.0-5.el7.x86_64
Comment 8 Sankar Ramalingam 2015-07-15 09:28:28 UTC 
I ran the CI tests on a RHEL7.2 machine and its PASSed.

INFO:lib389:ticket47664 was successfully verified.
PASSED
ds/dirsrvtests/tickets/ticket47664_test.py::test_ticket47664_final INFO:lib389:dir (sys) : //etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv', 'DS_ROOT': '', 'SERVER_DIR': '/usr/lib64/dirsrv', 'INST_DIR': '/usr/lib64/dirsrv/slapd-standalone', 'SERVERBIN_DIR': '/usr/sbin', 'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME': 'slapd'}

DEBUG:lib389:running: /usr/sbin/remove-ds.pl -i slapd-standalone 
Instance slapd-standalone removed.
INFO:ticket47664_test:Testcase PASSED
PASSED


INFO:lib389:ticket47824 was successfully verified.
PASSED
ds/dirsrvtests/tickets/ticket47824_test.py::test_ticket47824_final INFO:lib389:dir (sys) : //etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv', 'DS_ROOT': '', 'SERVER_DIR': '/usr/lib64/dirsrv', 'INST_DIR': '/usr/lib64/dirsrv/slapd-standalone', 'SERVERBIN_DIR': '/usr/sbin', 'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME': 'slapd'}

DEBUG:lib389:running: /usr/sbin/remove-ds.pl -i slapd-standalone 
Instance slapd-standalone removed.
INFO:ticket47824_test:Testcase PASSED
PASSED

Hence, marking the bug as Verified.
Comment 9 Sankar Ramalingam 2015-10-05 13:12:11 UTC 
Hi Noriko, should I repeat the steps mentioned in comment #1 to verify this with the new build or any other test runs?
Comment 10 Noriko Hosoi 2015-10-05 15:48:36 UTC 
(In reply to Sankar Ramalingam from comment #9)
> Hi Noriko, should I repeat the steps mentioned in comment #1 to verify this
> with the new build or any other test runs?

Sankar, please run the same CI test and TET pagedresults, again.  If they pass, set VERIFIED (once you see the status of this bug is turned to be ON_QA.  I haven't rebuilt the bits with the new fixes).

The issue is the bug(s) are often observed in the IPA/SSSD environment, but it is really hard to reproduce with the standalone DS.  I think we could have a test env for DS in the IPA/SSSD topology some time in the future...

Thanks,
--noriko
Comment 11 Sankar Ramalingam 2015-10-07 13:55:39 UTC 
1. Acceptance with 389-ds-bas-1.3.4.0-19:

############## Result  for  backend test :   filter run
    filter run elapse time : 00:03:55
    filter run Tests PASS      : 100% (273/273)

############## Result  for  backend test :   SIMPLEPAGED run
    SIMPLEPAGED run elapse time : 00:03:07
    SIMPLEPAGED run Tests PASS      : 100% (17/17)

2. Upstream tests:

INFO:lib389:attributeLevelRights: cn:rscwo
INFO:lib389:No cookie
INFO:lib389:Paged result search returned 20 entries in 5 pages.
INFO:lib389:ticket47664 was successfully verified.
PASSED

DEBUG:lib389:running: /usr/sbin/remove-ds.pl -i slapd-standalone 
Instance slapd-standalone removed.
INFO:ticket47664_test:Testcase PASSED
PASSED   ====== 2 passed in 35.51 seconds

Build tested:
[root@dhcp35-196 export]# rpm -qa |grep -i 389-ds
389-ds-base-1.3.4.0-19.el7.x86_64
389-ds-base-libs-1.3.4.0-19.el7.x86_64

Hence, marking the bug as Verified.
Comment 12 errata-xmlrpc 2015-11-19 11:42:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2351.html
Note You need to log in before you can comment on or make changes to this bug.