- openldap-bugs - openldap.org

(ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

Full_Name: Michael Ströder Version: RE24 (synced right now) OS: openSUSE 11.1 URL: Submission from: (NULL) (84.163.85.36) If I explicitly remove all object classes of an entry by value and re-add some of them the modify requests fail with "Type or value exists: modify/add: objectClass: value #1 already exists" Unfortunately I cannot provide a simple example for showing this. Specific configuration and data upon request since it's private data which MUST NOT be disclosed.

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by ando＠sys-net.it 19 Feb '09

19 Feb '09

hyc(a)symas.com wrote: > This seems like an odd situation, since we just went thru the validator above, > before attempting to normalize. In this case the attribute was > telephoneNumber, with a value of " " (a single space). The validator is > printableStringValidate, which accepts the value. But telephoneNumberNormalize > rejects it. Shouldn't the validator and normalizer always accept the same set > of input? I suggest you file an ITS :) I agree having normalize fail where validate would succeed should never happen. > Anyway, HEAD is fixed to just drop the illegal values, as Ando suggested. Thanks, I was about to look at it myself. 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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.14/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > back-meta doesn't check the return code from the normalizer when it's > normalizing the values of an attribute. As such, it can leave NULL slots in > a->a_nvals even though a->a_vals slots are all non-NULL. This seems like an odd situation, since we just went thru the validator above, before attempting to normalize. In this case the attribute was telephoneNumber, with a value of " " (a single space). The validator is printableStringValidate, which accepts the value. But telephoneNumberNormalize rejects it. Shouldn't the validator and normalizer always accept the same set of input? Anyway, HEAD is fixed to just drop the illegal values, as Ando suggested. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Looking over the code, there are some other problems. Other areas will drop values for various reasons (e.g., mapping out objectclass values). attr->a_numvals is set before these checks occur, and is not updated with the correct count later. I'll try to get some more fixes in for .15. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 19 Feb '09

19 Feb '09

ando(a)sys-net.it wrote: > A patch is coming. An essential part of the fix was missing. This is now fixed in HEAD, please test. 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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Sounds fine, will do that for a future rev. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5960) [rwm] segfault with slapcat on cn=config
by hyc＠symas.com 19 Feb '09

19 Feb '09

tchemineau(a)linagora.com wrote: > Full_Name: Thomas Chemineau > Version: RE24 and HEAD > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/thomas-chemineau-090219.patch > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Here is the following configuration : > > 8<---- > include /opt/openldap-2.4.14/etc/openldap/schema/core.schema > pidfile /opt/openldap-2.4.14/var/run/slapd.pid > argsfile /opt/openlidap-2.4.14/var/run/slapd.args > > database ldap > suffix "o=proxy" > uri ldap://server.lan > idassert-bind mode=none flags=prescriptive bindmethod=simple timeout=0 > network-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" > credentials="secret" > overlay rwm > rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > > database bdb > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /opt/openldap-2.4.14/var/openldap-data > index objectClass eq > 8<---- > > Initializing cn=config via slapd -f ... -F works fine. Now, if I want to do a > slapcat on cn=config with the following command, I had a segmentation fault. > > 8<---- > ldif_read_file: read entry file: > "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={1}ldap/olcOverlay={0}rwm.ldif" > => str2entry: "dn: olcOverlay={0}rwm > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > structuralObjectClass: olcRwmConfig > entryUUID: 8d7c51c4-239f-48f5-9ad5-751a50942eec > creatorsName: cn=config > createTimestamp: 20090219101010Z > entryCSN: 20090219101010.781439Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090219101010Z > " >>>> dnPrettyNormal:<olcOverlay={0}rwm> > <<< dnPrettyNormal:<olcOverlay={0}rwm>,<olcOverlay={0}rwm> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> > <= str2entry(olcOverlay={0}rwm) -> 0x124cbe48 > => test_filter > PRESENT > => access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > Erreur de segmentation > 8<---- > > I run GDB, and I had this: > > 8<---=> access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 46972859751984 (LWP 9462)] > 0x00000000004e08cf in rwm_cf_gen (c=0x7ffff26060b0) at rwm.c:2165 > 2165 for ( last = 0; !BER_BVISNULL( > &rwmap->rwm_bva_rewrite[ last ] ); last++ )- > 8<---- > > It seems that rwmap->rm_bva_rewrite is null. By the way, even if I correct this, > I have a similar issue in the rwm_db_destroy function, because rwmap->rwm_rw is > null too. So, freeing memory on a null pointer causes a segfault too. The above > patch corrects this problem. My apologies if I have missed something here. > > By the way, I make a mistake during the upload file on ftp.openldap.org, you > will find 2 files (both the same): servers.slapd.overlays.rwm.c.patch and the > other one specified above. > Thanks for the report. The last chunk of the patch was solving the wrong problem, so a different fix is in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by hyc＠symas.com 19 Feb '09

19 Feb '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Sharing the pointer to the supported controls would allow to use the >> actual set. Something along the line >> >> struct BackendDB { >> char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; >> char *be_ctrls; >> }; >> >> All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set >> it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf >> for the duration of an operation. Modules wouldn't be able to register >> new controls because the pointer is null otherwise. > > Of course, this wouldn't work since it implies modifying the BackendDB > structure, which is read-only :( backover.c 1.91 appears to partially revert rev 1.84, thus breaking ITS#5346 again. Investigating now... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5962) If slapcat can't join shm, it segfaults
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If the shm environment is not available, and you run slapcat, it segfaults: (gdb) bt #0 0x0000002a97256996 in hdb_tool_entry_open (be=0x70ca70, mode=0) at tools.c:108 #1 0x00000000004bb31b in slapcat (argc=7, argv=0x7fbffff8a8) at slapcat.c:73 #2 0x0000000000413274 in main (argc=7, argv=0x7fbffff8a8) at main.c:391

1 0

(ITS#5961) segfault if shm isn't available
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If OpenLDAP can't join the shm environment due to size issues, it segfaults: #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 192 config.c: No such file or directory. in config.c (gdb) bt #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 #1 0x0000002a95702a60 in ldap_int_thread_pool_wrapper (xpool=0x916ee0) at tpool.c:663 #2 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6

1 0

OpenLDAP crashes with segfault
by Tim Stone 19 Feb '09

19 Feb '09

Hello, I've installed OpenSuse 11 on a 64bit Intel Xeon. I configured one OpenLDAP as sync provider and the second one as consumer (RefeshOnly). But every time, a change is made in the provider and the consumer try to sync, the Provider crashs with segfault. I configured a own filter in syslog so that the slapd is logging in an exra logfile. The loglevel is -1. In the logfile are no related information. In the syslog I found following line: Feb 18 13:30:35 ldap-11 kernel: slapd[6151]: segfault at 8 ip 7f18d3a7b695 sp 40a60400 error 4 in libc-2.8.so[7f18d3a04000+14f000] To debug this, I turned corefiles on: sysctl -w kernel.core_pattern=/core sysctl -w kernel.core_uses_pid = 1 ulimit -c unlimited but no corefiles are created ... Can anyone help me? Thanx !!! Here my configuration Master/Provider: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/my.schema include /etc/openldap/schema/freeRadius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules sizelimit -1 disallow bind_anon access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self auth by anonymous auth by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none access to dn.subtree="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none loglevel -1 TLSCertificateFile /etc/openldap/certs/ldapmcrt.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSCertificateKeyFile /etc/openldap/certs/ldapmkey.pem database bdb monitoring off suffix "dc=mydom,dc=local" checkpoint 1024 5 rootdn "uid=administrator,dc=mydom,dc=local" rootpw "{SSHA}xxxxxxxxxxxx" directory /var/lib/ldap index objectClass,entryUUID,entryCSN,uid,cn eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Here my configuration Slave/Consumer: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/my.schema include /etc/openldap/schema/freeRadius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules sizelimit -1 disallow bind_anon access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self auth by anonymous auth by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none access to dn.subtree="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none loglevel -1 TLSCertificateFile /etc/openldap/certs/ldapscrt.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSCertificateKeyFile /etc/openldap/certs/ldapskey.pem database bdb monitoring off suffix "dc=mydom,dc=local" checkpoint 1024 5 rootdn "uid=administrator,dc=mydom,dc=local" rootpw "{SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" directory /var/lib/ldap index objectClass,entryUUID,entryCSN,uid,cn eq syncrepl rid=124 provider=ldap://ldapm:389 binddn=uid="fradius_replica,ou=specialusers,ou=_ma nagement,dc=mydom,dc=local" credentials="secretpass" type=refreshOnly interval=00:00:00:30 retry="60 10 300 3" searchbase="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple starttls=critical

2 1

Debug mode "fixes" authentication issue - race condition?
by Neil Garratt 19 Feb '09

19 Feb '09

Hi I'm testing OpenLDAP 2.3.27 (RPM) on Centos 5.2, used as a reverse proxy to AD. When slapd is run with debugging disabled (or set to 0), search requests throw the following error: DSID-0C090627: In order to perform this operation a successful bind must be completed on the connection. When run with any other debug value, it returns the results correctly. In both cases, the logs show a successful bind with the acl-bind user, the search finds the correct result, and acl's show access granted to read. The only difference is what is returned Non-working: Feb 19 11:17:20 localhost slapd[2916]: conn=0 op=1 ENTRY dn="cn=neil garratt,ou=admins,ou=users,ou=cape town,ou=networks unlimited,dc=nu,dc=local" Feb 19 11:17:20 localhost slapd[2916]: <= send_search_entry: conn 0 exit. Feb 19 11:17:20 localhost slapd[2916]: send_ldap_result: conn=0 op=1 p=3 Feb 19 11:17:20 localhost slapd[2916]: send_ldap_result: err=1 matched="" text="00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece" Feb 19 11:17:20 localhost slapd[2916]: send_ldap_response: msgid=2 tag=101 err=1 Feb 19 11:17:20 localhost slapd[2916]: conn=0 op=1 SEARCH RESULT tag=101 err=1 nentries=1 text=00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Working: Feb 19 11:18:42 localhost slapd[2949]: conn=0 op=1 ENTRY dn="cn=neil garratt,ou=admins,ou=users,ou=cape town,ou=networks unlimited,dc=nu,dc=local" Feb 19 11:18:42 localhost slapd[2949]: <= send_search_entry: conn 0 exit. Feb 19 11:18:42 localhost slapd[2949]: send_ldap_result: conn=0 op=1 p=3 Feb 19 11:18:42 localhost slapd[2949]: send_ldap_result: err=0 matched="" text="" Feb 19 11:18:42 localhost slapd[2949]: send_ldap_response: msgid=2 tag=101 err=0 Feb 19 11:18:42 localhost slapd[2949]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd.conf: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth loglevel any database ldap suffix "dc=nu,dc=local" uri "ldap://cptdc1.nu.local" acl-bind bindmethod=simple binddn="CN=LDAP,OU=Service Accounts,DC=nu,DC=local" credentials="xxxxxxxxxxxx"

2 1

(ITS#5960) [rwm] segfault with slapcat on cn=config
by tchemineau＠linagora.com 19 Feb '09

19 Feb '09

Full_Name: Thomas Chemineau Version: RE24 and HEAD OS: CentOS URL: ftp://ftp.openldap.org/incoming/thomas-chemineau-090219.patch Submission from: (NULL) (213.41.243.192) Hi, Here is the following configuration : 8<---- include /opt/openldap-2.4.14/etc/openldap/schema/core.schema pidfile /opt/openldap-2.4.14/var/run/slapd.pid argsfile /opt/openlidap-2.4.14/var/run/slapd.args database ldap suffix "o=proxy" uri ldap://server.lan idassert-bind mode=none flags=prescriptive bindmethod=simple timeout=0 network-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" credentials="secret" overlay rwm rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /opt/openldap-2.4.14/var/openldap-data index objectClass eq 8<---- Initializing cn=config via slapd -f ... -F works fine. Now, if I want to do a slapcat on cn=config with the following command, I had a segmentation fault. 8<---- ldif_read_file: read entry file: "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={1}ldap/olcOverlay={0}rwm.ldif" => str2entry: "dn: olcOverlay={0}rwm objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE structuralObjectClass: olcRwmConfig entryUUID: 8d7c51c4-239f-48f5-9ad5-751a50942eec creatorsName: cn=config createTimestamp: 20090219101010Z entryCSN: 20090219101010.781439Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090219101010Z " >>> dnPrettyNormal: <olcOverlay={0}rwm> <<< dnPrettyNormal: <olcOverlay={0}rwm>, <olcOverlay={0}rwm> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> <= str2entry(olcOverlay={0}rwm) -> 0x124cbe48 => test_filter PRESENT => access_allowed: search access to "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 Erreur de segmentation 8<---- I run GDB, and I had this: 8<---=> access_allowed: search access to "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46972859751984 (LWP 9462)] 0x00000000004e08cf in rwm_cf_gen (c=0x7ffff26060b0) at rwm.c:2165 2165 for ( last = 0; !BER_BVISNULL( &rwmap->rwm_bva_rewrite[ last ] ); last++ )- 8<---- It seems that rwmap->rm_bva_rewrite is null. By the way, even if I correct this, I have a similar issue in the rwm_db_destroy function, because rwmap->rwm_rw is null too. So, freeing memory on a null pointer causes a segfault too. The above patch corrects this problem. My apologies if I have missed something here. By the way, I make a mistake during the upload file on ftp.openldap.org, you will find 2 files (both the same): servers.slapd.overlays.rwm.c.patch and the other one specified above.

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by ando＠sys-net.it 18 Feb '09

18 Feb '09

hyc(a)OpenLDAP.org wrote: > back-meta doesn't check the return code from the normalizer when it's > normalizing the values of an attribute. As such, it can leave NULL slots in > a->a_nvals even though a->a_vals slots are all non-NULL. > > I was going to try just dup'ing the a->a_vals value into the slot, but I see > that in back-ldap for the same situation, the entire attribute is just dropped. > I suppose that's the safer path. In the spirit of doing what's best to return as much as possible, wouldn't it be preferable to just drop illegal values? And, of course, the whole attr if no legal values are left. 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(a)sys-net.it -----------------------------------

1 0

(ITS#5959) back-meta doesn't detect illegal values
by hyc＠OpenLDAP.org 18 Feb '09

18 Feb '09

Full_Name: Howard Chu Version: 2.4.14/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc back-meta doesn't check the return code from the normalizer when it's normalizing the values of an attribute. As such, it can leave NULL slots in a->a_nvals even though a->a_vals slots are all non-NULL. I was going to try just dup'ing the a->a_vals value into the slot, but I see that in back-ldap for the same situation, the entire attribute is just dropped. I suppose that's the safer path.

1 0

Re: (ITS#5957) ./scripts/test057-memberof-refint: Permission denied
by hyc＠symas.com 18 Feb '09

18 Feb '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.69.165) > > > michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test > [..] >>>>>> Starting test057-memberof-refint ... > ./scripts/all: line 47: ./scripts/test057-memberof-refint: Permission denied >>>>>> ./scripts/test057-memberof-refint failed (exit 126) > > michael@nb2:/usr/src/michael/openldap/HEAD/openldap/tests> ./run -b bdb test057 > run: test057 not found (or not executable) Should now be fixed in CVS. > > Even when doing > chmod a+x ./tests/scripts/test057-memberof-refint > there's something wrong: > > michael@nb2:/usr/src/michael/openldap/HEAD/openldap/tests> ./run -b bdb test057 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test057-memberof-refint... > running defines.sh > Test does not support bdb Looks perfectly normal. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by hyc＠symas.com 18 Feb '09

18 Feb '09

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Quanah Gibson-Mount wrote: >>>> --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: >>>> >>>>> Full_Name: Michael Str?der >>>>> Version: 2.4.14 >>>>> OS: SLES 10 >>>>> URL: >>>>> Submission from: (NULL) (193.197.158.1) >>>>> >>>>> >>>>> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >>>>> authz-regexp configuration is correct in slapd.conf >>>> What makes you think this is a bug with OpenLDAP and not cyrus-sasl? >>> Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 >>> which was running on the same machine before. With 2.3 when this file >>> was missing only this message was sent to syslog: "unable to open >>> Berkeley db /etc/sasldb2". Today it seg faults. >> What version of BDB was libsasl built with? What version was OpenLDAP built with? > > The BDB versions differ but it works when creating > /usr/lib/sasl2/slapd.conf with "auxprop_plugin: slapd". > > IIRC it also worked with OpenLDAP 2.3. Most likely the BDB versions were the same on your 2.3 build. You cannot have multiple BDB libraries in the same process (unless you build with symbol versioning). This is not an OpenLDAP bug. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5958) Segfault in test039
by hyc＠symas.com 18 Feb '09

18 Feb '09

This appears to be a dup of #5733. quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.14 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > When running test039 in a loop of 200 iterations, I consistently get a segfault > somewhere in the run (after around 100 iterations). The generated core shows: > > #0 0x000000397a32e2ed in raise () from /lib64/tls/libc.so.6 > (gdb) thr apply all bt > > Thread 18 (process 8852): > #0 0x000000397ae06ffb in pthread_join () from /lib64/tls/libpthread.so.0 > Thread 1 (process 9152): > #0 0x000000397a32e2ed in raise () from /lib64/tls/libc.so.6 > #1 0x000000397a32fa3e in abort () from /lib64/tls/libc.so.6 > #2 0x000000397a327ba1 in __assert_fail () from /lib64/tls/libc.so.6 > #3 0x0000002a974c19db in ldap_back_conn_delete (li=0x714ba0, lc=0x7b5430) at > bind.c:157 > #4 0x0000002a974c241f in ldap_back_freeconn (li=0x714ba0, lc=0x7b5430, > dolock=0) at bind.c:467 > #5 0x0000002a974c3d21 in ldap_back_release_conn_lock (li=0x714ba0, > lcp=0x4680b700, dolock=1) at bind.c:1144 > #6 0x0000002a974c2108 in ldap_back_bind (op=0x8356d0, rs=0x4680bd40) at > bind.c:355 > #7 0x00000000004b72e1 in overlay_op_walk (op=0x8356d0, rs=0x4680bd40, > which=op_bind, oi=0x6cebc0, on=0x0) at backover.c:672 > #8 0x00000000004b74a9 in over_op_func (op=0x8356d0, rs=0x4680bd40, > which=op_bind) at backover.c:724 > #9 0x00000000004b74f7 in over_op_bind (op=0x8356d0, rs=0x4680bd40) at > backover.c:734 > #10 0x000000000045990d in fe_op_bind (op=0x8356d0, rs=0x4680bd40) at bind.c:383 > #11 0x00000000004b72e1 in overlay_op_walk (op=0x8356d0, rs=0x4680bd40, > which=op_bind, oi=0x70f940, on=0x0) at backover.c:672 > #12 0x00000000004b74a9 in over_op_func (op=0x8356d0, rs=0x4680bd40, > which=op_bind) at backover.c:724 > #13 0x00000000004b74f7 in over_op_bind (op=0x8356d0, rs=0x4680bd40) at > backover.c:734 > #14 0x000000000045905e in do_bind (op=0x8356d0, rs=0x4680bd40) at bind.c:205 > #15 0x0000000000433adb in connection_operation (ctx=0x4680bea0, arg_v=0x8356d0) > at connection.c:1097 > #16 0x000000000043400a in connection_read_thread (ctx=0x4680bea0, argv=0x14) at > connection.c:1223 > #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at > tpool.c:663 > #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 > #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 > #20 0x0000000000000000 in ?? () > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5958) Segfault in test039
by quanah＠OpenLDAP.org 18 Feb '09

18 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.14 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When running test039 in a loop of 200 iterations, I consistently get a segfault somewhere in the run (after around 100 iterations). The generated core shows: #0 0x000000397a32e2ed in raise () from /lib64/tls/libc.so.6 (gdb) thr apply all bt Thread 18 (process 8852): #0 0x000000397ae06ffb in pthread_join () from /lib64/tls/libpthread.so.0 #1 0x0000002a9556beb4 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 #2 0x000000000043109a in slapd_daemon () at daemon.c:2665 #3 0x000000000041437d in main (argc=8, argv=0x7fbffff318) at main.c:948 Thread 17 (process 8867): #0 0x000000397a3c63dc in epoll_wait () from /lib64/tls/libc.so.6 #1 0x00000000004302a6 in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #2 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 16 (process 8882): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x2a9820d360, timeout=0x40fff350) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x2a9820d360, msgid=527, all=0, timeout=0x40fff560, result=0x40fff550) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x2a9820d360, msgid=527, all=0, timeout=0x40fff560, result=0x40fff550) at result.c:121 #4 0x0000002a974c0969 in ldap_back_search (op=0x79db90, rs=0x41000d40) at search.c:274 #5 0x00000000004b3ac9 in glue_sub_search (op=0x79db90, rs=0x41000d40, b0=0x40fff7c0, on=0x6ceda0) at backglue.c:340 #6 0x00000000004b4282 in glue_op_search (op=0x79db90, rs=0x41000d40) at backglue.c:473 #7 0x00000000004b724d in overlay_op_walk (op=0x79db90, rs=0x41000d40, which=op_search, oi=0x6cebc0, on=0x6ceda0) at backover.c:662 #8 0x00000000004b74a9 in over_op_func (op=0x79db90, rs=0x41000d40, which=op_search) at backover.c:724 #9 0x00000000004b753f in over_op_search (op=0x79db90, rs=0x41000d40) at backover.c:746 #10 0x00000000004371ba in fe_op_search (op=0x79db90, rs=0x41000d40) at search.c:366 #11 0x00000000004b72e1 in overlay_op_walk (op=0x79db90, rs=0x41000d40, which=op_search, oi=0x70f940, on=0x0) at backover.c:672 #12 0x00000000004b74a9 in over_op_func (op=0x79db90, rs=0x41000d40, which=op_search) at backover.c:724 #13 0x00000000004b753f in over_op_search (op=0x79db90, rs=0x41000d40) at backover.c:746 #14 0x0000000000436b72 in do_search (op=0x79db90, rs=0x41000d40) at search.c:217 #15 0x0000000000433adb in connection_operation (ctx=0x41000ea0, arg_v=0x79db90) at connection.c:1097 #16 0x000000000043400a in connection_read_thread (ctx=0x41000ea0, argv=0x1d) at connection.c:1223 #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #20 0x0000000000000000 in ?? () Thread 15 (process 8981): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x7dbd80, timeout=0x41800350) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x7dbd80, msgid=294, all=0, timeout=0x41800560, result=0x41800550) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x7dbd80, msgid=294, all=0, timeout=0x41800560, result=0x41800550) at result.c:121 #4 0x0000002a974c0969 in ldap_back_search (op=0x7beb90, rs=0x41801d40) at search.c:274 #5 0x00000000004b3ac9 in glue_sub_search (op=0x7beb90, rs=0x41801d40, b0=0x418007c0, on=0x6ceda0) at backglue.c:340 #6 0x00000000004b411d in glue_op_search (op=0x7beb90, rs=0x41801d40) at backglue.c:455 #7 0x00000000004b724d in overlay_op_walk (op=0x7beb90, rs=0x41801d40, which=op_search, oi=0x6cebc0, on=0x6ceda0) at backover.c:662 #8 0x00000000004b74a9 in over_op_func (op=0x7beb90, rs=0x41801d40, which=op_search) at backover.c:724 #9 0x00000000004b753f in over_op_search (op=0x7beb90, rs=0x41801d40) at backover.c:746 #10 0x00000000004371ba in fe_op_search (op=0x7beb90, rs=0x41801d40) at search.c:366 #11 0x00000000004b72e1 in overlay_op_walk (op=0x7beb90, rs=0x41801d40, which=op_search, oi=0x70f940, on=0x0) at backover.c:672 #12 0x00000000004b74a9 in over_op_func (op=0x7beb90, rs=0x41801d40, which=op_search) at backover.c:724 #13 0x00000000004b753f in over_op_search (op=0x7beb90, rs=0x41801d40) at backover.c:746 #14 0x0000000000436b72 in do_search (op=0x7beb90, rs=0x41801d40) at search.c:217 #15 0x0000000000433adb in connection_operation (ctx=0x41801ea0, arg_v=0x7beb90) at connection.c:1097 #16 0x000000000043400a in connection_read_thread (ctx=0x41801ea0, argv=0xb) at connection.c:1223 #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #20 0x0000000000000000 in ?? () Thread 14 (process 9010): #0 0x000000397a3d16ab in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 #1 0x000000397a5305d0 in run_fp () from /lib64/tls/libc.so.6 #2 0x02046e6300000000 in ?? () #3 0x000000397a35ab91 in fputs () from /lib64/tls/libc.so.6 #4 0x000000004200126e in ?? () #5 0x0000000000000000 in ?? () Thread 13 (process 9082): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x7f2740, timeout=0x42802350) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x7f2740, msgid=647, all=0, timeout=0x42802560, result=0x42802550) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x7f2740, msgid=647, all=0, timeout=0x42802560, result=0x42802550) at result.c:121 #4 0x0000002a974c0969 in ldap_back_search (op=0x7da280, rs=0x42803d40) at search.c:274 #5 0x00000000004b3ac9 in glue_sub_search (op=0x7da280, rs=0x42803d40, b0=0x428027c0, on=0x6ceda0) at backglue.c:340 #6 0x00000000004b4282 in glue_op_search (op=0x7da280, rs=0x42803d40) at backglue.c:473 #7 0x00000000004b724d in overlay_op_walk (op=0x7da280, rs=0x42803d40, which=op_search, oi=0x6cebc0, on=0x6ceda0) at backover.c:662 #8 0x00000000004b74a9 in over_op_func (op=0x7da280, rs=0x42803d40, which=op_search) at backover.c:724 #9 0x00000000004b753f in over_op_search (op=0x7da280, rs=0x42803d40) at backover.c:746 #10 0x00000000004371ba in fe_op_search (op=0x7da280, rs=0x42803d40) at search.c:366 #11 0x00000000004b72e1 in overlay_op_walk (op=0x7da280, rs=0x42803d40, which=op_search, oi=0x70f940, on=0x0) at backover.c:672 #12 0x00000000004b74a9 in over_op_func (op=0x7da280, rs=0x42803d40, which=op_search) at backover.c:724 #13 0x00000000004b753f in over_op_search (op=0x7da280, rs=0x42803d40) at backover.c:746 #14 0x0000000000436b72 in do_search (op=0x7da280, rs=0x42803d40) at search.c:217 #15 0x0000000000433adb in connection_operation (ctx=0x42803ea0, arg_v=0x7da280) at connection.c:1097 #16 0x000000000043400a in connection_read_thread (ctx=0x42803ea0, argv=0x2d) at connection.c:1223 #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #20 0x0000000000000000 in ?? () Thread 12 (process 9097): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x83dae0, timeout=0x43004450) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x83dae0, msgid=284, all=1, timeout=0x43004520, result=0x43004518) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x83dae0, msgid=284, all=1, timeout=0x43004520, result=0x43004518) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x7ee470, op=0x7e5520, rs=0x43004d40, msgid=284, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c8263 in ldap_back_modrdn (op=0x7e5520, rs=0x43004d40) at modrdn.c:95 #6 0x00000000004b72e1 in overlay_op_walk (op=0x7e5520, rs=0x43004d40, which=op_modrdn, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x7e5520, rs=0x43004d40, which=op_modrdn) at backover.c:724 #8 0x00000000004b75ab in over_op_modrdn (op=0x7e5520, rs=0x43004d40) at backover.c:764 #9 0x0000000000455683 in fe_op_modrdn (op=0x7e5520, rs=0x43004d40) at modrdn.c:314 #10 0x00000000004b72e1 in overlay_op_walk (op=0x7e5520, rs=0x43004d40, which=op_modrdn, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x7e5520, rs=0x43004d40, which=op_modrdn) at backover.c:724 #12 0x00000000004b75ab in over_op_modrdn (op=0x7e5520, rs=0x43004d40) at backover.c:764 #13 0x0000000000454fe6 in do_modrdn (op=0x7e5520, rs=0x43004d40) at modrdn.c:186 #14 0x0000000000433adb in connection_operation (ctx=0x43004ea0, arg_v=0x7e5520) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x43004ea0, argv=0x12) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 11 (process 9101): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x7d15d0, timeout=0x43805510) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x7d15d0, msgid=20, all=1, timeout=0x438055e0, result=0x438055d8) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x7d15d0, msgid=20, all=1, timeout=0x438055e0, result=0x438055d8) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x7d1b40, op=0x7f1470, rs=0x43805d40, msgid=20, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c7ad9 in ldap_back_delete (op=0x7f1470, rs=0x43805d40) at delete.c:62 #6 0x00000000004b72e1 in overlay_op_walk (op=0x7f1470, rs=0x43805d40, which=op_delete, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x7f1470, rs=0x43805d40, which=op_delete) at backover.c:724 #8 0x00000000004b75f3 in over_op_delete (op=0x7f1470, rs=0x43805d40) at backover.c:776 #9 0x0000000000454234 in fe_op_delete (op=0x7f1470, rs=0x43805d40) at delete.c:174 #10 0x00000000004b72e1 in overlay_op_walk (op=0x7f1470, rs=0x43805d40, which=op_delete, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x7f1470, rs=0x43805d40, which=op_delete) at backover.c:724 #12 0x00000000004b75f3 in over_op_delete (op=0x7f1470, rs=0x43805d40) at backover.c:776 #13 0x0000000000453f64 in do_delete (op=0x7f1470, rs=0x43805d40) at delete.c:95 #14 0x0000000000433adb in connection_operation (ctx=0x43805ea0, arg_v=0x7f1470) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x43805ea0, argv=0x23) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 10 (process 9102): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x7b56d0, timeout=0x440062c0) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x7b56d0, msgid=547, all=1, timeout=0x44006390, result=0x44006388) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x7b56d0, msgid=547, all=1, timeout=0x44006390, result=0x44006388) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x7b5650, op=0x7f19e0, rs=0x44006d40, msgid=547, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c76ad in ldap_back_add (op=0x7f19e0, rs=0x44006d40) at add.c:104 #6 0x00000000004b72e1 in overlay_op_walk (op=0x7f19e0, rs=0x44006d40, which=op_add, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x7f19e0, rs=0x44006d40, which=op_add) at backover.c:724 #8 0x00000000004b75cf in over_op_add (op=0x7f19e0, rs=0x44006d40) at backover.c:770 #9 0x000000000043c605 in fe_op_add (op=0x7f19e0, rs=0x44006d40) at add.c:334 #10 0x00000000004b72e1 in overlay_op_walk (op=0x7f19e0, rs=0x44006d40, which=op_add, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x7f19e0, rs=0x44006d40, which=op_add) at backover.c:724 #12 0x00000000004b75cf in over_op_add (op=0x7f19e0, rs=0x44006d40) at backover.c:770 #13 0x000000000043c068 in do_add (op=0x7f19e0, rs=0x44006d40) at add.c:194 #14 0x0000000000433adb in connection_operation (ctx=0x44006ea0, arg_v=0x7f19e0) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x44006ea0, argv=0x1c) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 9 (process 9121): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x83e9c0, timeout=0x44806350) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x83e9c0, msgid=720, all=0, timeout=0x44806560, result=0x44806550) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x83e9c0, msgid=720, all=0, timeout=0x44806560, result=0x44806550) at result.c:121 #4 0x0000002a974c0969 in ldap_back_search (op=0x7cbb20, rs=0x44807d40) at search.c:274 #5 0x00000000004b3ac9 in glue_sub_search (op=0x7cbb20, rs=0x44807d40, b0=0x448067c0, on=0x6ceda0) at backglue.c:340 #6 0x00000000004b4282 in glue_op_search (op=0x7cbb20, rs=0x44807d40) at backglue.c:473 #7 0x00000000004b724d in overlay_op_walk (op=0x7cbb20, rs=0x44807d40, which=op_search, oi=0x6cebc0, on=0x6ceda0) at backover.c:662 #8 0x00000000004b74a9 in over_op_func (op=0x7cbb20, rs=0x44807d40, which=op_search) at backover.c:724 #9 0x00000000004b753f in over_op_search (op=0x7cbb20, rs=0x44807d40) at backover.c:746 #10 0x00000000004371ba in fe_op_search (op=0x7cbb20, rs=0x44807d40) at search.c:366 #11 0x00000000004b72e1 in overlay_op_walk (op=0x7cbb20, rs=0x44807d40, which=op_search, oi=0x70f940, on=0x0) at backover.c:672 #12 0x00000000004b74a9 in over_op_func (op=0x7cbb20, rs=0x44807d40, which=op_search) at backover.c:724 #13 0x00000000004b753f in over_op_search (op=0x7cbb20, rs=0x44807d40) at backover.c:746 #14 0x0000000000436b72 in do_search (op=0x7cbb20, rs=0x44807d40) at search.c:217 #15 0x0000000000433adb in connection_operation (ctx=0x44807ea0, arg_v=0x7cbb20) at connection.c:1097 #16 0x000000000043400a in connection_read_thread (ctx=0x44807ea0, argv=0x15) at connection.c:1223 #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #20 0x0000000000000000 in ?? () Thread 8 (process 9132): #0 0x000000397a3d16ab in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 #1 0x000000397a5305d0 in run_fp () from /lib64/tls/libc.so.6 #2 0x0000002a9822e120 in ?? () #3 0x000000397a35ab91 in fputs () from /lib64/tls/libc.so.6 #4 0x0000000045008280 in ?? () #5 0x0000002a956ba1a1 in ber_scanf (ber=0xa7463656c65735f, fmt=0x746e695f7061646c <Address 0x746e695f7061646c out of bounds>) at decode.c:811 #6 0x6c757365725f6573 in ?? () #7 0x0000002a95000a74 in ?? () #8 0x000000017a52e680 in ?? () #9 0x0000003000000028 in ?? () #10 0x0000000045008580 in ?? () #11 0x00000000450084c0 in ?? () #12 0x0000002a956be9c1 in ber_error_print (data=Cannot access memory at address 0x7261705f70616464 ) at bprint.c:87 Cannot access memory at address 0x7261705f7061646c Thread 7 (process 9133): #0 0x000000397a3d16dd in __lll_mutex_unlock_wake () from /lib64/tls/libc.so.6 #1 0x000000397a5305d0 in run_fp () from /lib64/tls/libc.so.6 #2 0x0000000045807db0 in ?? () #3 0x000000397a35abac in fputs () from /lib64/tls/libc.so.6 #4 0x0000000045807d60 in ?? () #5 0x000000397a364e48 in _IO_new_file_write () from /lib64/tls/libc.so.6 #6 0x000000397a365037 in _IO_new_file_xsputn () from /lib64/tls/libc.so.6 #7 0x000000397a35ab33 in fputs () from /lib64/tls/libc.so.6 #8 0x0000002a956be97a in ber_error_print (data=0x45807db0 "** ld 0x7eece0 Outstanding Requests:\n") at bprint.c:79 #9 0x0000002a95590ffb in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2a955a5d68 "** ld %p Outstanding Requests:\n") at print.c:60 #10 0x0000002a95587414 in ldap_dump_requests_and_responses (ld=0x7eece0) at request.c:844 #11 0x0000002a9556d466 in wait4msg (ld=0x7eece0, msgid=532, all=0, timeout=0x45808560, result=0x45808550) at result.c:306 #12 0x0000002a9556cedc in ldap_result (ld=0x7eece0, msgid=532, all=0, timeout=0x45808560, result=0x45808550) at result.c:121 #13 0x0000002a974c0969 in ldap_back_search (op=0x802820, rs=0x45809d40) at search.c:274 #14 0x00000000004b3ac9 in glue_sub_search (op=0x802820, rs=0x45809d40, b0=0x458087c0, on=0x6ceda0) at backglue.c:340 #15 0x00000000004b4282 in glue_op_search (op=0x802820, rs=0x45809d40) at backglue.c:473 #16 0x00000000004b724d in overlay_op_walk (op=0x802820, rs=0x45809d40, which=op_search, oi=0x6cebc0, on=0x6ceda0) at backover.c:662 #17 0x00000000004b74a9 in over_op_func (op=0x802820, rs=0x45809d40, which=op_search) at backover.c:724 #18 0x00000000004b753f in over_op_search (op=0x802820, rs=0x45809d40) at backover.c:746 #19 0x00000000004371ba in fe_op_search (op=0x802820, rs=0x45809d40) at search.c:366 #20 0x00000000004b72e1 in overlay_op_walk (op=0x802820, rs=0x45809d40, which=op_search, oi=0x70f940, on=0x0) at backover.c:672 #21 0x00000000004b74a9 in over_op_func (op=0x802820, rs=0x45809d40, which=op_search) at backover.c:724 #22 0x00000000004b753f in over_op_search (op=0x802820, rs=0x45809d40) at backover.c:746 #23 0x0000000000436b72 in do_search (op=0x802820, rs=0x45809d40) at search.c:217 #24 0x0000000000433adb in connection_operation (ctx=0x45809ea0, arg_v=0x802820) at connection.c:1097 #25 0x000000000043400a in connection_read_thread (ctx=0x45809ea0, argv=0x8) at connection.c:1223 #26 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #27 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #28 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #29 0x0000000000000000 in ?? () Thread 6 (process 9135): #0 0x000000397a3d16dd in __lll_mutex_unlock_wake () from /lib64/tls/libc.so.6 #1 0x000000397a5305d0 in run_fp () from /lib64/tls/libc.so.6 #2 0x0000000046008d30 in ?? () #3 0x000000397a35abac in fputs () from /lib64/tls/libc.so.6 #4 0x0000002a956bebb7 in ber_pvt_log_printf (errlvl=57, loglvl=2052253312, fmt=0xa3a72656220296d <Address 0xa3a72656220296d out of bounds>) at bprint.c:124 #5 0x756f286e64327662 in ?? () #6 0x2c7370756f72473d in ?? () #7 0x706d6178653d6364 in ?? () #8 0x6f633d63642c656c in ?? () #9 0x00000a20303d296d in ?? () #10 0x67736d3164616572 in ?? () #11 0x37783020646c203a in ?? () #12 0x736d203039643263 in ?? () #13 0x6d20393820646967 in ?? () #14 0x7420656761737365 in ?? () #15 0x7261657320657079 in ?? () #16 0x7972746e652d6863 in ?? () #17 0x00000000407f000a in ?? () #18 0x0000000046008f40 in ?? () #19 0x000000397a361f54 in vsnprintf () from /lib64/tls/libc.so.6 #20 0x0000002a95590ffb in ldap_log_printf (ld=0x458b48f845894800, loglvl=275619333, fmt=0xf8458948d0ff008b <Address 0xf8458948d0ff008b out of bounds>) at print.c:60 #21 0xbd894800000500ec in ?? () #22 0xff44b589ffffff48 in ?? () #23 0xffff688d8948ffff in ?? () #24 0xffffff7085894cff in ?? () #25 0x0fffffff788d894c in ?? () #26 0xfffb00858948c0b6 in ?? () #27 0xfffffb008d8b48ff in ?? () #28 0x000000008d048d48 in ?? () #29 0x480000003b0d8d48 in ?? () #30 0x2948fffffb008d89 in ?? () #31 0x458d48fffffb0085 in ?? () #32 0xfffffb008d8b48ff in ?? () #33 0x290ff178290fe1ff in ?? () #34 0x290fd168290fe170 in ?? () #35 0x290fb158290fc160 in ?? () #36 0x290f9148290fa150 in ?? () #37 0xffff389589488140 in ?? () #38 0x18fffffb1085c7ff in ?? () #39 0xfffb1485c7000000 in ?? () #40 0x458d4800000030ff in ?? () #41 0xfffffb1885894810 in ?? () #42 0x48ffffff508d8d48 in ?? () #43 0x8b48fffffb208d89 in ?? () #44 0x3883480010676205 in ?? () #45 0x6755058b48417400 in ?? () #46 0xfffb10958d480010 in ?? () #47 0xffffff388d8b48ff in ?? () #48 0x8b48ffffff44b58b in ?? () #49 0x0d8b4cffffff48bd in ?? () #50 0x49108b4c00106723 in ?? () #51 0x49fe8948f289d089 in ?? () #52 0x4100000000b8398b in ?? () #53 0x0c958d485cebd2ff in ?? () #54 0x00000002befffffb in ?? () #55 0x98e5e800000000bf in ?? () #56 0xffffff2f85c6ffff in ?? () #57 0xfffffb108d8d4800 in ?? () #58 0x48ffffff38958b48 in ?? () #59 0xffbefffffb30bd8d in ?? () #60 0xffff975fe8000003 in ?? () #61 0xe083fffffb0c858b in ?? () #62 0x058b481374c08510 in ?? () #63 0x30bd8d48001066e3 in ?? () #64 0xd0ff008b48fffffb in ?? () #65 0x55c3c900000001b8 in ?? () #66 0x04f0ec8148e58948 in ?? () #67 0xffffff4cbd890000 in ?? () #68 0x8948ffffff48b589 in ?? () #69 0x85894cffffff688d in ?? () #70 0x788d894cffffff70 in ?? () #71 0x8948c0b60fffffff in ?? () #72 0x8d8b48fffffb1085 in ?? () #73 0x8d048d48fffffb10 in ?? () #74 0x3b0d8d4800000000 in ?? () #75 0xfb108d8948000000 in ?? () #76 0xfffb10852948ffff in ?? () #77 0x8d8b48ff458d48ff in ?? () #78 0x290fe1fffffffb10 in ?? () #79 0x290fe170290ff178 in ?? () #80 0x290fc160290fd168 in ?? () #81 0x290fa150290fb158 in ?? () #82 0x89488140290f9148 in ?? () #83 0xbd8348ffffff4095 in ?? () #84 0x481f7500ffffff40 in ?? () #85 0x80ba000043a10d8d in ?? () #86 0x4375358d48000000 in ?? () #87 0x0043a13d8d480000 in ?? () #88 0x858bffff9641e800 in ?? () #89 0xff4c8523ffffff48 in ?? () #90 0x85c70c75c085ffff in ?? () #91 0x00000000fffffb1c in ?? () #92 0xfffffb2085c770eb in ?? () #93 0xfb2485c700000018 in ?? () #94 0x8d4800000030ffff in ?? () #95 0xfffb288589481045 in ?? () #96 0xffffff508d8d48ff in ?? () #97 0xc6fffffb308d8948 in ?? () #98 0x8d4800ffffff3f85 in ?? () #99 0x958b48fffffb208d in ?? () #100 0x40bd8d48ffffff40 in ?? () #101 0x000003ffbefffffb in ?? () [this goes for pages] #1877 0x8348f175fff88348 in ?? () #1878 0x489090c3c95b08c4 in ?? () #1879 0xffff60cfe808ec83 in ?? () Cannot access memory at address 0x2a956c23e1 Thread 5 (process 9157): #0 0x000000397a3d16dd in __lll_mutex_unlock_wake () from /lib64/tls/libc.so.6 #1 0x000000397a5305d0 in run_fp () from /lib64/tls/libc.so.6 #2 0x000000004700ab90 in ?? () #3 0x000000397a35abac in fputs () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (process 9165): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x8387b0, timeout=0x4780d2c0) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x8387b0, msgid=257, all=1, timeout=0x4780d390, result=0x4780d388) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x8387b0, msgid=257, all=1, timeout=0x4780d390, result=0x4780d388) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x838ae0, op=0x833480, rs=0x4780dd40, msgid=257, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c76ad in ldap_back_add (op=0x833480, rs=0x4780dd40) at add.c:104 #6 0x00000000004b72e1 in overlay_op_walk (op=0x833480, rs=0x4780dd40, which=op_add, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x833480, rs=0x4780dd40, which=op_add) at backover.c:724 #8 0x00000000004b75cf in over_op_add (op=0x833480, rs=0x4780dd40) at backover.c:770 #9 0x000000000043c605 in fe_op_add (op=0x833480, rs=0x4780dd40) at add.c:334 #10 0x00000000004b72e1 in overlay_op_walk (op=0x833480, rs=0x4780dd40, which=op_add, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x833480, rs=0x4780dd40, which=op_add) at backover.c:724 #12 0x00000000004b75cf in over_op_add (op=0x833480, rs=0x4780dd40) at backover.c:770 #13 0x000000000043c068 in do_add (op=0x833480, rs=0x4780dd40) at add.c:194 #14 0x0000000000433adb in connection_operation (ctx=0x4780dea0, arg_v=0x833480) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x4780dea0, argv=0x2b) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 3 (process 9166): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x839030, timeout=0x4800e510) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x839030, msgid=593, all=1, timeout=0x4800e5e0, result=0x4800e5d8) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x839030, msgid=593, all=1, timeout=0x4800e5e0, result=0x4800e5d8) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x7cb7e0, op=0x83a020, rs=0x4800ed40, msgid=593, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c7ad9 in ldap_back_delete (op=0x83a020, rs=0x4800ed40) at delete.c:62 #6 0x00000000004b72e1 in overlay_op_walk (op=0x83a020, rs=0x4800ed40, which=op_delete, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x83a020, rs=0x4800ed40, which=op_delete) at backover.c:724 #8 0x00000000004b75f3 in over_op_delete (op=0x83a020, rs=0x4800ed40) at backover.c:776 #9 0x0000000000454234 in fe_op_delete (op=0x83a020, rs=0x4800ed40) at delete.c:174 #10 0x00000000004b72e1 in overlay_op_walk (op=0x83a020, rs=0x4800ed40, which=op_delete, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x83a020, rs=0x4800ed40, which=op_delete) at backover.c:724 #12 0x00000000004b75f3 in over_op_delete (op=0x83a020, rs=0x4800ed40) at backover.c:776 #13 0x0000000000453f64 in do_delete (op=0x83a020, rs=0x4800ed40) at delete.c:95 #14 0x0000000000433adb in connection_operation (ctx=0x4800eea0, arg_v=0x83a020) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x4800eea0, argv=0xd) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 2 (process 9167): #0 0x000000397a3bd1e2 in poll () from /lib64/tls/libc.so.6 #1 0x0000002a9558a662 in ldap_int_select (ld=0x8036f0, timeout=0x4880f450) at os-ip.c:1056 #2 0x0000002a9556d52d in wait4msg (ld=0x8036f0, msgid=15, all=1, timeout=0x4880f520, result=0x4880f518) at result.c:336 #3 0x0000002a9556cedc in ldap_result (ld=0x8036f0, msgid=15, all=1, timeout=0x4880f520, result=0x4880f518) at result.c:121 #4 0x0000002a974c4e62 in ldap_back_op_result (lc=0x803670, op=0x837070, rs=0x4880fd40, msgid=15, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1695 #5 0x0000002a974c8263 in ldap_back_modrdn (op=0x837070, rs=0x4880fd40) at modrdn.c:95 #6 0x00000000004b72e1 in overlay_op_walk (op=0x837070, rs=0x4880fd40, which=op_modrdn, oi=0x6cebc0, on=0x0) at backover.c:672 #7 0x00000000004b74a9 in over_op_func (op=0x837070, rs=0x4880fd40, which=op_modrdn) at backover.c:724 #8 0x00000000004b75ab in over_op_modrdn (op=0x837070, rs=0x4880fd40) at backover.c:764 #9 0x0000000000455683 in fe_op_modrdn (op=0x837070, rs=0x4880fd40) at modrdn.c:314 #10 0x00000000004b72e1 in overlay_op_walk (op=0x837070, rs=0x4880fd40, which=op_modrdn, oi=0x70f940, on=0x0) at backover.c:672 #11 0x00000000004b74a9 in over_op_func (op=0x837070, rs=0x4880fd40, which=op_modrdn) at backover.c:724 #12 0x00000000004b75ab in over_op_modrdn (op=0x837070, rs=0x4880fd40) at backover.c:764 #13 0x0000000000454fe6 in do_modrdn (op=0x837070, rs=0x4880fd40) at modrdn.c:186 #14 0x0000000000433adb in connection_operation (ctx=0x4880fea0, arg_v=0x837070) at connection.c:1097 #15 0x000000000043400a in connection_read_thread (ctx=0x4880fea0, argv=0x17) at connection.c:1223 #16 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #17 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 1 (process 9152): #0 0x000000397a32e2ed in raise () from /lib64/tls/libc.so.6 #1 0x000000397a32fa3e in abort () from /lib64/tls/libc.so.6 #2 0x000000397a327ba1 in __assert_fail () from /lib64/tls/libc.so.6 #3 0x0000002a974c19db in ldap_back_conn_delete (li=0x714ba0, lc=0x7b5430) at bind.c:157 #4 0x0000002a974c241f in ldap_back_freeconn (li=0x714ba0, lc=0x7b5430, dolock=0) at bind.c:467 #5 0x0000002a974c3d21 in ldap_back_release_conn_lock (li=0x714ba0, lcp=0x4680b700, dolock=1) at bind.c:1144 #6 0x0000002a974c2108 in ldap_back_bind (op=0x8356d0, rs=0x4680bd40) at bind.c:355 #7 0x00000000004b72e1 in overlay_op_walk (op=0x8356d0, rs=0x4680bd40, which=op_bind, oi=0x6cebc0, on=0x0) at backover.c:672 #8 0x00000000004b74a9 in over_op_func (op=0x8356d0, rs=0x4680bd40, which=op_bind) at backover.c:724 #9 0x00000000004b74f7 in over_op_bind (op=0x8356d0, rs=0x4680bd40) at backover.c:734 #10 0x000000000045990d in fe_op_bind (op=0x8356d0, rs=0x4680bd40) at bind.c:383 #11 0x00000000004b72e1 in overlay_op_walk (op=0x8356d0, rs=0x4680bd40, which=op_bind, oi=0x70f940, on=0x0) at backover.c:672 #12 0x00000000004b74a9 in over_op_func (op=0x8356d0, rs=0x4680bd40, which=op_bind) at backover.c:724 #13 0x00000000004b74f7 in over_op_bind (op=0x8356d0, rs=0x4680bd40) at backover.c:734 #14 0x000000000045905e in do_bind (op=0x8356d0, rs=0x4680bd40) at bind.c:205 #15 0x0000000000433adb in connection_operation (ctx=0x4680bea0, arg_v=0x8356d0) at connection.c:1097 #16 0x000000000043400a in connection_read_thread (ctx=0x4680bea0, argv=0x14) at connection.c:1223 #17 0x0000002a9556aac0 in ldap_int_thread_pool_wrapper (xpool=0x6b02c0) at tpool.c:663 #18 0x000000397ae0610a in start_thread () from /lib64/tls/libpthread.so.0 #19 0x000000397a3c6003 in clone () from /lib64/tls/libc.so.6 #20 0x0000000000000000 in ?? ()

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by michael＠stroeder.com 18 Feb '09

18 Feb '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Quanah Gibson-Mount wrote: >>> --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: >>> >>>> Full_Name: Michael Str?der >>>> Version: 2.4.14 >>>> OS: SLES 10 >>>> URL: >>>> Submission from: (NULL) (193.197.158.1) >>>> >>>> >>>> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >>>> authz-regexp configuration is correct in slapd.conf >>> What makes you think this is a bug with OpenLDAP and not cyrus-sasl? >> Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 >> which was running on the same machine before. With 2.3 when this file >> was missing only this message was sent to syslog: "unable to open >> Berkeley db /etc/sasldb2". Today it seg faults. > > What version of BDB was libsasl built with? What version was OpenLDAP built with? The BDB versions differ but it works when creating /usr/lib/sasl2/slapd.conf with "auxprop_plugin: slapd". IIRC it also worked with OpenLDAP 2.3. Ciao, Michael.

1 0

(ITS#5957) ./scripts/test057-memberof-refint: Permission denied
by michael＠stroeder.com 18 Feb '09

18 Feb '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.69.165) michael@nb2:/usr/src/michael/openldap/HEAD/openldap> make test [..] >>>>> Starting test057-memberof-refint ... ./scripts/all: line 47: ./scripts/test057-memberof-refint: Permission denied >>>>> ./scripts/test057-memberof-refint failed (exit 126) michael@nb2:/usr/src/michael/openldap/HEAD/openldap/tests> ./run -b bdb test057 run: test057 not found (or not executable) Even when doing chmod a+x ./tests/scripts/test057-memberof-refint there's something wrong: michael@nb2:/usr/src/michael/openldap/HEAD/openldap/tests> ./run -b bdb test057 Cleaning up test run directory leftover from previous run. Running ./scripts/test057-memberof-refint... running defines.sh Test does not support bdb

1 0

Re: (ITS#3952) Patch: 'make test' does not fail at all errors
by michael＠stroeder.com 18 Feb '09

18 Feb '09

Howard Chu wrote: > I suspect that all of these issues have been fixed in subsequent releases. Can > we close this? I don't know how to really test it and therefore I just believe your statement that it's fixed => no objections against closing this ITS. Ciao, Michael.

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by hyc＠symas.com 18 Feb '09

18 Feb '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: >> >>> Full_Name: Michael Str?der >>> Version: 2.4.14 >>> OS: SLES 10 >>> URL: >>> Submission from: (NULL) (193.197.158.1) >>> >>> >>> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >>> authz-regexp configuration is correct in slapd.conf >> What makes you think this is a bug with OpenLDAP and not cyrus-sasl? > > Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 > which was running on the same machine before. With 2.3 when this file > was missing only this message was sent to syslog: "unable to open > Berkeley db /etc/sasldb2". Today it seg faults. What version of BDB was libsasl built with? What version was OpenLDAP built with? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by michael＠stroeder.com 18 Feb '09

18 Feb '09

Quanah Gibson-Mount wrote: > --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: 2.4.14 >> OS: SLES 10 >> URL: >> Submission from: (NULL) (193.197.158.1) >> >> >> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >> authz-regexp configuration is correct in slapd.conf > > What makes you think this is a bug with OpenLDAP and not cyrus-sasl? Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 which was running on the same machine before. With 2.3 when this file was missing only this message was sent to syslog: "unable to open Berkeley db /etc/sasldb2". Today it seg faults. Ciao, Michael.

1 0

Re: (ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by jclarke＠linagora.com 17 Feb '09

17 Feb '09

hyc(a)symas.com wrote: > jclarke(a)linagora.com wrote: > >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: CentOS >> URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi all, >> >> It seems that when adding syncrepl consumers to be->be_syncinfo, they are added >> in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete >> on cn=config from be->be_syncinfo, the nth entry in the list is removed, which >> is not the same one. >> > > Thanks for the patch, fixed in HEAD. > This ITS' subject was rather vague. Just for reference, this problem only affected in-memory structures, not the actual data in cn=config. Always solved by restarting slapd, thus.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs