Good afternoon to all,
I've been trying to track down a problem that has been eluding me for the past week and I think I've narrowed it down to the rwm overlay. When the 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 the memory map if its useful)
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.
I haven't found any documentation that mentions limitations and/or bugs when using rwm with translucent. Here is portion of my configuration file (am I stacking the overlays correctly?):
###############################################
# 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
###############################################
The use case for this configuration is to create a custom view for clients who are using nss ldap. I'm using a translucent overlay to provide attributes that are missing on the remote server. The rwm overlay is used to map attributes that exist, but are named differently on the remote server. I'm also using a rewrite rule to manipulate incoming search filters.
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 can file an ITS if need be, but I thought I'd ask before doing so. Maybe my configuration is wrong or I have missed a piece of documentation explaining why my configuration doesn't work.
Bryan
Bryan Mesich wrote:
The use case for this configuration is to create a custom view for clients who are using nss ldap. I'm using a translucent overlay to provide attributes that are missing on the remote server. The rwm overlay is used to map attributes that exist, but are named differently on the remote server. I'm also using a rewrite rule to manipulate incoming search filters.
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 can file an ITS if need be, but I thought I'd ask before doing so. Maybe my configuration is wrong or I have missed a piece of documentation explaining why my configuration doesn't work.
Given the number of overlays and the number of possible permutations of configurations, it should be clear that we don't document every combination.
However, no configuration should ever cause a crash. Any crash is always a bug and should be reported to the ITS.
Bryan Mesich wrote:
Good afternoon to all,
I've been trying to track down a problem that has been eluding me for the past week and I think I've narrowed it down to the rwm overlay. When the 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 the memory map if its useful)
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.
I haven't found any documentation that mentions limitations and/or bugs when using rwm with translucent. Here is portion of my configuration file (am I stacking the overlays correctly?):
###############################################
# 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/";
^^^^^^ there is an error here
overlay rwm #rwm-rewriteEngine on #rwm-rewriteContext searchFilter #rwm-rewriteRule "^(.*objectClass=)posixAccount(.*)" "$1inetOrgPerson$2" ":@" #rwm-map attribute uidNumber NID
###############################################
The use case for this configuration is to create a custom view for clients who are using nss ldap. I'm using a translucent overlay to provide attributes that are missing on the remote server. The rwm overlay is used to map attributes that exist, but are named differently on the remote server. I'm also using a rewrite rule to manipulate incoming search filters.
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 can file an ITS if need be, but I thought I'd ask before doing so. Maybe my configuration is wrong or I have missed a piece of documentation explaining why my configuration doesn't work.
I suggest you file an ITS. The reason for this double free is that the cleanup call of slapo-rwm deletes the filterstr set by slapo-rwm and replaces it with the original one. However, the translucent_search() call subsequently sets the now deleted pointer to slapo-rwm's filterstr into the operation structure.
This needs to be reworked, and the ITS will allow to track this rework.
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, Feb 09, 2009 at 10:41:29PM +0100, Pierangelo Masarati wrote:
I can file an ITS if need be, but I thought I'd ask before doing so. Maybe my configuration is wrong or I have missed a piece of documentation explaining why my configuration doesn't work.
I suggest you file an ITS. The reason for this double free is that the cleanup call of slapo-rwm deletes the filterstr set by slapo-rwm and replaces it with the original one. However, the translucent_search() call subsequently sets the now deleted pointer to slapo-rwm's filterstr into the operation structure.
This needs to be reworked, and the ITS will allow to track this rework.
Thanks for your imput (Howard too). I filed an ITS against this issue (ITS 5941).
Thanks again,
Bryan
openldap-software@openldap.org