May 2024 - openldap-bugs

[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9398 Issue ID: 9398 Summary: Stale accesslog cookie due to unclean shutdown Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db. Depending on the syncprov overlay checkpoint settings (usually no checkpointing is enabled on the accesslog db) this can cause the system to refuse engage in replication at startup. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 20 Aug '24

20 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10147] New: Bind dn is getting malformed inside ldap_sasl_bind function
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10147 Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: satishkumar1728(a)gmail.com Target Milestone: --- Hi team, We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr" Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10175] New: Secure LDAP is not working on GCC 10.3.0
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10175 Issue ID: 10175 Summary: Secure LDAP is not working on GCC 10.3.0 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, We have recently migrated our C++ application which is using OpenLDAP 2.6 to GCC version 10.3.0. We are observing difference in LDAP behavior. The non-secure version of LDAP is able to return the result in GCC 10.3.0, however when we switch to secure LDAP, it is not able to return with result. There was no compilation / build issue observed while building our application. Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility issues over GCC 10.3.0? If there are any issues identified over this version, how to resolve those? in which version fixes for them are available? Thanks, Vivek -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10060] New: libldap: ldap_result return value differs depending on if a search response is already in the response list or not
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10060 Issue ID: 10060 Summary: libldap: ldap_result return value differs depending on if a search response is already in the response list or not Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: david(a)hardeman.nu Target Milestone: --- ldap_result(3) is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… On this line, ldap_result will call wait4msg: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… wait4msg is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If a response for a given msgid is already stored in the response list, and all=1, the whole message chain will be returned by the call from wait4msg to chkResponseList here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And rc will be set on the next line to the head of the message chain. If a response for a given msgid is *not* already stored in the response list, wait4msg will eventually call try_read1msg here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If try_read1msg manages to receive the final search result message for a given msgid, it will be noted here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… The whole chain will be returned here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And the return code will be the tag of the *last* message in the chain, as opposed to the *first* message in the chain: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Which will result in different return codes for chains of multiple messages (i.e. search results with all=1). -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10138] New: Allow generating multiple nested read transactions from a write transaction
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10138 Issue ID: 10138 Summary: Allow generating multiple nested read transactions from a write transaction Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hello, I have a feature request. Would it be possible to read a database from the point of view of a non-yet-committed write transaction? What I want to do is to write a lot of entries into a database, use a couple of threads to read those entries (using MDB_NOTLS) to generate a lot of new entries (that will be written to disk and then once the generation is done, drop the read-transaction handles and write (with MDB_APPEND) those new entries from disk into LMDB. This would have been possible if I had committed the first entries, but unfortunately, it is impossible. I need to do this in the same transaction. Have a great day, kero -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10220] New: Feature Request: new option for append-only write transaction
by openldap-its＠openldap.org 31 May '24

31 May '24

https://bugs.openldap.org/show_bug.cgi?id=10220 Issue ID: 10220 Summary: Feature Request: new option for append-only write transaction Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xhtang518(a)gmail.com Target Milestone: --- My project uses LMDB to store values larger than 100KB, and rarely delete values. So I can afford wasting some space on free pages, then LMDB can reduce 4KB-write operations and improve write performance when committing write transactions. I suppose this feature is not hard to implement: just pretend the free-list is empty in this transaction if the new option is present. Is this feature reasonable? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10182] New: slapo-alias doesn't work with static operational attributes
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10182 Issue ID: 10182 Summary: slapo-alias doesn't work with static operational attributes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- It only checks in rs->sr_operational_attrs which is for dynamically generated opattrs, and ignores them if they're in the entry itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10104] New: Add alias overlay to contrib
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10104 Issue ID: 10104 Summary: Add alias overlay to contrib Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10188] New: autogroup doesn't allow a group to be a member of another group
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10188 Issue ID: 10188 Summary: autogroup doesn't allow a group to be a member of another group Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Try setting up autogroup (autogroup-attrset groupOfURLs memberURL member) and loading the following ldif. You'll notice that neither group is marked as a member: dn: cn=test objectClass: device dn: cn=group,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(description=a member) memberURL: ldap:///cn=test??sub?(description=I'm in) description: a member dn: cn=member,cn=test objectClass: device description: I'm in dn: cn=another,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(objectclass=groupOfURLs) description: I'm in Just set up mygroupOfURLs with at least a MAY that includes "cn $ description $ member $ memberURL" somehow, e.g. objectClass ( NetscapeLDAPobjectClass:33.1 NAME 'mygroupOfURLs' SUP groupofurls STRUCTURAL MAY member ) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10172] New: check for writability of directory of logfile during startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10172 Issue ID: 10172 Summary: check for writability of directory of logfile during startup Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Even if the logfile itself is writable, if the enclosing directory is not writable then slapd won't be able to perform logfile rotation. Check for this when the logfile is being configured. This will prevent starting up with a bad config, but we still can't do anything about it if the directory's perms are changed while slapd is already running. Logging an error message in that situation would likely fill all disk space with that error message. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10103] New: Contrib OIDs inconsistent
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10103 Issue ID: 10103 Summary: Contrib OIDs inconsistent Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When the latest batch of contrib overlays were added, the OIDs list wasn't updated and OIDs inside the code populated properly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10197] New: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10197 Issue ID: 10197 Summary: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- This happens when a new target is added via cn=config. In asyncmeta's case it can lead to too many connection structures allocated, although it seems operational. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10204] New: Slapd crashes when attempting to use DN as constraint attribute
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10204 Issue ID: 10204 Summary: Slapd crashes when attempting to use DN as constraint attribute Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: eresendiz(a)symas.com Target Milestone: --- Created attachment 1016 --> https://bugs.openldap.org/attachment.cgi?id=1016&action=edit Crash output When adding a to the constraint overlay with a constraintattribute that contains a 'dn' filter the slapd process crashes. Please see below for more detail. Very readily produceable with any kind of non-existent attribute specified in the attribute list. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=7400 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10193] New: Asyncmeta starts more than one timeout loop per database
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10193 Issue ID: 10193 Summary: Asyncmeta starts more than one timeout loop per database Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- By design, there should be always exactly one timeout loop task per database, it is a balance to make sure timeout checks do not throttle traffic processing. For some reason, there seems to be more than one. This is only visible if slapd is started with -dasyncmeta log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10207] New: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26))
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10207 Issue ID: 10207 Summary: configure: Syntax error: Unterminated quoted string (2.6.8 (RE26)) Product: OpenLDAP Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Created attachment 1017 --> https://bugs.openldap.org/attachment.cgi?id=1017&action=edit Patch for configure.ac Testing RE26 (2.6.8) On FreeBSD and NetBSD, configure fails with the following error: checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes ./configure: 13865: Syntax error: Unterminated quoted string Patch for configure.ac attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10161] New: Move nested group support to its own overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10161 Issue ID: 10161 Summary: Move nested group support to its own overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Adding the feature to dynlist has made that code overly complex, along with killing performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10185] New: autogroup doesn't populate members in newly added dynamic groups
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10185 Issue ID: 10185 Summary: autogroup doesn't populate members in newly added dynamic groups Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This was broken in 316afb1190c4fa8d96dc56b38b41f4a6ffb163e9 ITS#6970 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10183] New: ldapadd jump option
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10183 Issue ID: 10183 Summary: ldapadd jump option Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Same as the jump option added for slapadd in ITS#4555. Should have been added long ago. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10167] New: slapo-memberof should have a way of reacting to a member entry being added after group referencing it
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10167 Issue ID: 10167 Summary: slapo-memberof should have a way of reacting to a member entry being added after group referencing it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a group (with member: values) is added before the member entries exist, the memberof values never get populated. This can happen e.g. during replication. No idea how it meshes with the refint functionality of memberof if it's indeed reconcilable at all. Silly example (Hird's memberof will be empty): ```ldif dn: cn=GNU,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hurd,ou=Groups,dc=example,dc=com dn: cn=Hurd,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hird,ou=Groups,dc=example,dc=com member: cn=Roger Rabbit,ou=People,dc=example,dc=com dn: cn=Hird,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Tweety Bird,ou=People,dc=example,dc=com member: cn=Hurd,ou=Groups,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10186] New: Overlay response callbacks should ignore op->o_abandon
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10186 Issue ID: 10186 Summary: Overlay response callbacks should ignore op->o_abandon Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Overlays that need to perform other DB write operations in their response callbacks usually create a new Operation by copying the existing *op. If the op had its o_abandon flag set, then every op the overlay starts will be immediately abandoned instead of executing. They should zero out the op->o_abandon flag, because the fact that the response callback got invoked means the original operation already completed. If the main op actually observed the abandon request, the response callbacks wouldn't have gotten triggered. This in particular affects the memberof overlay, which must perform other modifications after the main op completes. It also affects the contrib autogroup overlay. It might be relevant for accesslog as well, but I haven't looked at that yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10176] New: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10176 Issue ID: 10176 Summary: new atexit() call to atexit(ldap_exit_tls_destroy) in 2.5.17 crashes AIX application Product: OpenLDAP Version: 2.5.17 Hardware: Other OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: philip.miloslavsky(a)gmail.com Target Milestone: --- We have a long standing openldap application that's being ported from 2.4.58 to 2.5.17. On ppc AIX (but not on linux for which we also build), when we exit the main application we get a crash in exit() because it is trying to run the atexit which LDAP regsitered, but ldap has already been unloaded and the unloading caused that atexit function pointer to become zero. So I tracked it to this line of code in ldap 2.5.17 that was not there in 2.4.58 libraries/libldap/tls2.c: atexit( ldap_exit_tls_destroy ); If I remove that line of code, my issue goes away. So, now on to dlcose and atexit. So we have a main kernel (irisdb), a C++ library (ldap.so) that we wrote that calls ldap client libraries, and the 2 actual openldap libraries which ldap.so is linked against. During irisdb exit (the h command) irisdb does call dlclose on ldap.so, which as a side effect results in the unloading of the 2 official openldap libraries, but no one calls unatexit() (on the 0x09001000a04947a8 below). After the 3 libraries are unloaded, the atexit registration is still there but its been replaced with zeroes. At what point in this process should we call unatexit or some LDAP function and why does this sequence of events work right on linux but not AIX? [5] stop in ldap_unbind_s (dbx) c [1] stopped in unload_sharedlib at line 7793 in file "/nethome/pmilosla/perforce/projects/OpenLDAP4/kernel/common/src/cdzf.c" ($t1) 7793 if (!libptr) (dbx) where unload_sharedlib(libptr = 0x0000000000000004), line 7793 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) 0x09001000a04947a8/2x 0x09001000a04947a8: 0900 0000 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0900 0000 0491 8ec0 (dbx) c [3] stopped in dlclose at 0x90000000029da40 ($t1) 0x90000000029da40 (dlclose) 7c0802a6 mflr r0 (dbx) where dlclose(0x4) at 0x90000000029da40 unload_sharedlib(libptr = 0x0000000000000004), line 7804 in "cdzf.c" UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c" ResetZFETable(), line 7940 in "cdzf.c" zfrundown(), line 10135 in "cdzf.c" chsub2(), line 3480 in "dmisc2.c" chalt(flag = 1), line 3222 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" (dbx) p zfetabdescp->fnameptr "/home/gavlak/gavlakcre7424/bin/ldap.so" (dbx) c [2] stopped in exit at 0x9000000002524a0 ($t1) 0x9000000002524a0 (exit) 7c0802a6 mflr r0 (dbx) 0x09001000a04947a8/4x 0x09001000a04947a8: 0000 0000 0000 0000 (dbx) c Illegal instruction in . at 0x0 ($t1) 0x0000000000000000 00000000 Invalid opcode. (dbx) where .() at 0x0 exit(??) at 0x900000000252610 syshalt(a = 0), line 6925 in "emisc.c" chalt(flag = 1), line 3227 in "dmisc2.c" Chaltcmd(), line 3146 in "dmisc2.c" -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10170] New: accesslog breaks if internal ops done in startup
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10170 Issue ID: 10170 Summary: accesslog breaks if internal ops done in startup Product: OpenLDAP Version: 2.5.17 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- If some other overlay performs some internal operations in its db_open handler, before all DBs and overlays are fully initialized, and accesslog_response is invoked, it may crash if its logDB hasn't been initialized yet. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2024