Bug 1934067
Summary: | dbscan crash due to a segmentation fault when looking up for key "=ffffffff-ffffffff-ffffffff-ffffffff" | ||
---|---|---|---|
Product: | Red Hat Directory Server | Reporter: | Têko Mihinto <tmihinto> |
Component: | 389-ds-base | Assignee: | Pierre Rogier <progier> |
Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> |
Severity: | high | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
Priority: | medium | ||
Version: | 11.3 | CC: | afarley, bsmejkal, gkimetto, ldap-maint, mreynolds, progier, tbordaz |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | dirsrv-12.1 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | redhat-ds-12-9010020220729141346.12_1_910 | Doc Type: | Bug Fix |
Doc Text: |
Cause: Search key is not properly reset if it is not found in the database.
Consequence: An attempt to free data that are not allocated in the heap generated a core dump (with SIGSEGV exception) in the final cleanup (i.e: just before exiting).
Fix: data is now reset.
Result: No more core dump in this case.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-12-06 15:44:40 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Têko Mihinto
2021-03-02 12:36:50 UTC
I looked at dbscan code im 1.4.3 branch and my suspicion was right: we should clear the key (to avoid freeing it) while handling user specified key error case. if (ret != 0) { printf("Can't find key '%s'\n", find_key); ret = 1; + key->data = NULL; goto done; } Note: The bug was fixed upstream a few month ago while preparing the lmdb migration because bdb data struct are no more used but encapsuled by dbimpl API struct (that takes care whether the data must be freed or not). Since dbimpl is a very large change we should not try to frontport it but rather use the above solution instead. The good news is that the crash occurs when doing the final cleanup just before exiting so all data are rightly displayed) The bad news is that the key is missing in the db which is not expected according to the initial issue error message ... And to answer the last customer question: The fact that ns-slapd is running is OK and should not be an issue. 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 (redhat-ds:12 bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2022:8836 |