Full_Name: Bryan Mesich Version: 2.4.13 OS: RHEL 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) When a rwm overlay is used in conjunction with the translucent overlay, slapd dies with the following error and backtrace: *** glibc detected *** ./libexec/slapd: double free or corruption (fasttop): 0x0860ca38 *** ======= Backtrace: ========= /lib/libc.so.6[0x5ceac1] /lib/libc.so.6(cfree+0x90)[0x5d20f0] ./libexec/slapd(do_search+0x10e)[0x807bbfe] ./libexec/slapd[0x8079845] ./libexec/slapd[0x8079c12] ./libexec/slapd[0x816d504] /lib/libpthread.so.0[0x6f750b] /lib/libc.so.6(clone+0x5e)[0x638b2e] I have been able to reproduce this error in 2.4.11, 2.4.13 and the CVS HEAD as of Mon Feb 9 11:13:04 CST 2009. Here is portion of my configuration file: ############################################### # database backend modules to load moduleload back_ldap.la # overlay modules to load moduleload translucent.la moduleload rwm.la # local database database bdb suffix "dc=nodak,dc=edu" rootdn "cn=root,dc=nodak,dc=edu" rootpw secret directory /var/lib/ldap2.4 overlay translucent uri "ldap://ldap.nodak.edu/"; overlay rwm #rwm-rewriteEngine on #rwm-rewriteContext searchFilter #rwm-rewriteRule "^(.*objectClass=)posixAccount(.*)" "$1inetOrgPerson$2" ":@" #rwm-map attribute uidNumber NID ############################################### Simply declaring the rwm overlay (as shown in my configuration) is enough to produce the error when used with a translucent overlay. Slapd will usually answer one request after being started before tipping over. I'm open to testing if needed. Thanks in advance, Bryan
The problem can be easily reproduced, no need for further testing. However, I don't see an easy and clear fix right now. In the meanwhile, you should stack something in between to obtain the desired result. Having another proxy in between that deals with rwm could help. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
changed notes moved from Incoming to Software Bugs
changed notes
bryan.mesich@ndsu.edu wrote: > Full_Name: Bryan Mesich > Version: 2.4.13 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) > > > When a rwm overlay is used in conjunction with the translucent overlay, slapd > dies with the following error and backtrace: I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could also address yours. Can you check? You need to either build HEAD code, or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> 1.119 to 2.4.16. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
On Mon, Apr 20, 2009 at 12:12:48PM +0200, Pierangelo Masarati wrote: >> Full_Name: Bryan Mesich >> Version: 2.4.13 >> OS: RHEL 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) >> >> >> When a rwm overlay is used in conjunction with the translucent overlay, slapd >> dies with the following error and backtrace: > > I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could > also address yours. Can you check? You need to either build HEAD code, > or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> > 1.119 to 2.4.16. I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 and recompiled. Slapd answers one request and then dies with a segmentation fault: connection_get(14): got connid=1 connection_read(14): checking for input on id=1 ber_get_next Segmentation fault I can send you the full debug output if it would be helpful. Thanks, Bryan
bryan.mesich@ndsu.edu wrote: > I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 > and recompiled. Slapd answers one request and then dies with > a segmentation fault: > > connection_get(14): got connid=3D1 > connection_read(14): checking for input on id=3D1 > ber_get_next > Segmentation fault > > I can send you the full debug output if it would be helpful. I'll ask you to send it unless I can easily reproduce the issue myself. Thanks for your time. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter
I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to have a deeper look at this. Thanks Wouter
> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.
> In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local. I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue.
translucent/rwm duplicate of ITS#6070?
Ondrej to investigate further
trunk/RE25: • fc1bcaf9 by Ondřej Kuzník at 2021-01-18T14:36:16+00:00 ITS#5941 manage callbacks to coexist with other overlays