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.
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.
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.
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.
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.
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.
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.
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.
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.
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.