Full_Name: Larry Bartz Version: 1.2beta OS: Linux 2.0.35 (Redhat 5.1) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.49.118.18) I've configured and loaded multiple databases (Sleepycat 2.3.16) under a single slapd instance. As per required practice, the slapd and the DB are compiled without threads, and with the define for alias dereferencing. The suffix(s) of the databases are all siblings under a common parent DN. The parent of all the siblings has its own DB, which is (per the UMICH Admin Guide) last in the list. The databases contain alias entries in which the aliasedObjectName is the DN of an entry in another database. BEHAVIOR I GOT: "ldif2ldbm -n [dbnumber]" loads the separate databases just fine slapd starts and runs just fine client access, using any of the defined rootdn(s) as base is fine, until... ALIAS DEREFERENCING: slapd, as observed via "-d 255" 1. checks current database (in which the alias resides) for the ID of the referenced DN - finds nothing - dn2id NOID 2. parses back through the RDNs of the referenced DN, checking each against the current DB, looking for a branch to follow - finds no match, because the DN couldn't possibly be in this DB - dn2id NOID, until the RDNs are exhausted 3. returns "DANGLING ALIAS" error AND dumps core! BEHAVIOR I EXPECTED: I expected 1 & 2, above. But instead of 3, I expected that slapd would: parse back through the DN of the aliasedObjectName, evaluate the suffix(s) of the OTHER databases it is holding, choose an appropriate DB to continue the search, and at least give it a try. My expectation is entirely naive, since I have not inspected the code. But whether or not it's designed to work this way, shouldn't it?
At 07:45 PM 2/2/99 GMT, lbartz@parnelli.indy.cr.irs.gov wrote: >Full_Name: Larry Bartz >Version: 1.2beta >OS: Linux 2.0.35 (Redhat 5.1) >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (209.49.118.18) > > >I've configured and loaded multiple databases (Sleepycat 2.3.16) under a >single slapd instance. As per required practice, the slapd and the DB are >compiled without threads, and with the define for alias dereferencing. > >The suffix(s) of the databases are all siblings under a common parent DN. >The parent of all the siblings has its own DB, which is (per the UMICH Admin >Guide) last in the list. > >The databases contain alias entries in which the aliasedObjectName is >the DN of an entry in another database. > >BEHAVIOR I GOT: > > "ldif2ldbm -n [dbnumber]" loads the separate databases just fine > > slapd starts and runs just fine > > client access, using any of the defined rootdn(s) as base is fine, until... > > ALIAS DEREFERENCING: > slapd, as observed via "-d 255" > > 1. checks current database (in which the alias >resides) > for the ID of the referenced DN > - finds nothing - dn2id NOID > 2. parses back through the RDNs of the referenced DN, > checking each against the current DB, looking for > a branch to follow > - finds no match, because the DN couldn't possibly > be in this DB - dn2id NOID, until the RDNs are > exhausted > 3. returns "DANGLING ALIAS" error AND dumps core! Of course, the crash shouldn't occur, however: Returning an error is expected in this case. I would suspect either an LDAP_ALIAS_PROBLEM (or LDAP_ALIAS_DEREF_PROBLEM). In OpenLDAP, each backend is considerred to be a virtual DSA. Aliases across backends cannot be followed as the software is currently designed. As far as the crash is concerned, please followup with a relevant logs (-d 133) and a debugger backtrace from the core file. Kurt
Hi Larry, please keep in mind there are at least two issues currently with the alias code and the way you are trying to use it: it was not written with multiple databases in mind, and there are locking problems I am trying to work through. I wrote the code before the locking was implemented in the id2entry calls so there are incompatibilities. I have created a patch (not yet committed) that fixes some of the locking issues but not all. The remaining problem is that alias dereferencing requires looking at other entries in the directory, but all calls to id2entry are blocking calls. This means there can always be deadlock situations since we may need to look at the same entry more than once, whether for alias dereferencing or other comparison operations. This may be due to my imperfect understanding of the locking code, I am reviewing it and have sent Kurt a couple of questions. It seems to me there needs to be a non-blocking call to read an entry. The alias code was meant to work with a single suffix associated with a single database, but I'll take a look at dereferencing across multiple databases. While the slapd code is geared to using a single db it should be possible to scan through the backend list and pick out the db based on the suffix and then search through the other db by switching backends. Comments anyone? Neither of those issues should lead to a core dump though, please send me the full debug log, it may be due to a missing NULL check in the current code. Thanks. lbartz@parnelli.indy.cr.irs.gov wrote: > > Full_Name: Larry Bartz > Version: 1.2beta > OS: Linux 2.0.35 (Redhat 5.1) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.49.118.18) > > I've configured and loaded multiple databases (Sleepycat 2.3.16) under a > single slapd instance. As per required practice, the slapd and the DB are > compiled without threads, and with the define for alias dereferencing. > > The suffix(s) of the databases are all siblings under a common parent DN. > The parent of all the siblings has its own DB, which is (per the UMICH Admin > Guide) last in the list. > > The databases contain alias entries in which the aliasedObjectName is > the DN of an entry in another database. > > BEHAVIOR I GOT: > > "ldif2ldbm -n [dbnumber]" loads the separate databases just fine > > slapd starts and runs just fine > > client access, using any of the defined rootdn(s) as base is fine, until... > > ALIAS DEREFERENCING: > slapd, as observed via "-d 255" > > 1. checks current database (in which the alias > resides) > for the ID of the referenced DN > - finds nothing - dn2id NOID > 2. parses back through the RDNs of the referenced DN, > checking each against the current DB, looking for > a branch to follow > - finds no match, because the DN couldn't possibly > be in this DB - dn2id NOID, until the RDNs are > exhausted > 3. returns "DANGLING ALIAS" error AND dumps core! > > BEHAVIOR I EXPECTED: > > I expected 1 & 2, above. But instead of 3, I expected that slapd would: > > parse back through the DN of the aliasedObjectName, > evaluate the suffix(s) of the OTHER databases it is holding, > choose an appropriate DB to continue the search, > and at least give it a try. > > My expectation is entirely naive, since I have not inspected the code. But > whether or not it's designed to work this way, shouldn't it? -- Will Ballantyne GEMS Technical Architect mailto:Will.Ballantyne@gems1.gov.bc.ca
I find the following gdb output puzzling, as it indicates calls to pthread_create. I compiled without threads. Here is the script I ran to set my env and call configure, followed by the gdb backtrace. The diagnostic from slapd -d 133 is attached. ################## ## WITHOUT THREADS CC=gcc export CC CPPFLAGS="-I/u1/serverHOMES/db/sleepycat/db-2.3.16/include/ -DSLAPD_ALIAS_DEREF" export CPPFLAGS ## DEBUG CFLAGS="-g" ## OPTIMIZED ## CFLAGS="-O2" export CFLAGS LDFLAGS=-L/u1/serverHOMES/db/sleepycat/db-2.3.16/lib/ export LDFLAGS ./configure --prefix=/u1/serverHOMES/directory/openLDAP/1.2beta --without-threads --enable-phonetic --with-gnu-ld --enable-aclgroups --with-ldbm-api=db2 --disable-kerberos --disable-ldapd --disable-x-compile And here is the gdb output. GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `slapd -d 133'. Program terminated with signal 11, Segmentation fault. find_solib: Can't read pathname for load map: Input/output error #0 0x80686f6 in derefAlias_r (be=0x80b4d88, conn=0x80beca0, op=0x80cf278, e=0x0) at alias.c:46 46 ( depth < be->be_maxDerefDepth ); (gdb) bt #0 0x80686f6 in derefAlias_r (be=0x80b4d88, conn=0x80beca0, op=0x80cf278, e=0x0) at alias.c:46 #1 0x8068dd9 in derefDN (be=0x80b4d88, conn=0x80beca0, op=0x80cf278, dn=0x80c96b8 "CN=YAYA PAUL J 95TB,OU=CHIEF INFORMATION OFFICER,OU=NATIONAL OFFICE,OU=ORGANIZATION,OU=INTERNAL REVENUE SERVICE,OU=DEPARTMENT OF THE TREASURY,O=U.S. GOVERNMENT,C=US") at alias.c:218 #2 0x806789d in ldbm_back_search (be=0x80b4d88, conn=0x80beca0, op=0x80cf278, base=0x80c96b8 "CN=YAYA PAUL J 95TB,OU=CHIEF INFORMATION OFFICER,OU=NATIONAL OFFICE,OU=ORGANIZATION,OU=INTERNAL REVENUE SERVICE,OU=DEPARTMENT OF THE TREASURY,O=U.S. GOVERNMENT,C=US", scope=0, deref=2, slimit=1500, tlimit=70, filter=0x80ab258, filterstr=0x80cc460 "(objectclass=*)", attrs=0x80cf118, attrsonly=0) at search.c:83 #3 0x804e366 in do_search (conn=0x80beca0, op=0x80cf278) at search.c:149 #4 0x804d7f6 in connection_operation (arg_v=0x80d41d0) at connection.c:74 #5 0x8074fa9 in pthread_create (tid=0x80cf2a0, attr=0xbffff9cc, func=0x804d5ec <connection_operation>, arg=0x80d41d0) at thread.c:534 #6 0x804ddab in connection_activity (conn=0x80beca0) at connection.c:225 #7 0x804d336 in slapd_daemon (port=0x185) at daemon.c:374 #8 0x8074fa9 in pthread_create (tid=0x80ab11c, attr=0x0, func=0x804a794 <slapd_daemon>, arg=0x185) at thread.c:534 #9 0x804a2dd in main (argc=3, argv=0xbffffcdc) at main.c:194 -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| "Kurt D. Zeilenga" wrote: > > At 07:45 PM 2/2/99 GMT, lbartz@parnelli.indy.cr.irs.gov wrote: > >Full_Name: Larry Bartz > >Version: 1.2beta > >OS: Linux 2.0.35 (Redhat 5.1) > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (209.49.118.18) > > > > > >I've configured and loaded multiple databases (Sleepycat 2.3.16) under a > >single slapd instance. As per required practice, the slapd and the DB are > >compiled without threads, and with the define for alias dereferencing. > > > >The suffix(s) of the databases are all siblings under a common parent DN. > >The parent of all the siblings has its own DB, which is (per the UMICH Admin > >Guide) last in the list. > > > >The databases contain alias entries in which the aliasedObjectName is > >the DN of an entry in another database. > > > >BEHAVIOR I GOT: > > > > "ldif2ldbm -n [dbnumber]" loads the separate databases just fine > > > > slapd starts and runs just fine > > > > client access, using any of the defined rootdn(s) as base is fine, until... > > > > ALIAS DEREFERENCING: > > slapd, as observed via "-d 255" > > > > 1. checks current database (in which the alias > >resides) > > for the ID of the referenced DN > > - finds nothing - dn2id NOID > > 2. parses back through the RDNs of the referenced DN, > > checking each against the current DB, looking for > > a branch to follow > > - finds no match, because the DN couldn't possibly > > be in this DB - dn2id NOID, until the RDNs are > > exhausted > > 3. returns "DANGLING ALIAS" error AND dumps core! > > Of course, the crash shouldn't occur, however: > > Returning an error is expected in this case. I would > suspect either an LDAP_ALIAS_PROBLEM (or > LDAP_ALIAS_DEREF_PROBLEM). In OpenLDAP, each backend is > considerred to be a virtual DSA. Aliases across backends > cannot be followed as the software is currently designed. > > As far as the crash is concerned, please followup with a > relevant logs (-d 133) and a debugger backtrace from the core > file. > > Kurt
moved from Incoming to Software Bugs
changed notes
changed notes changed state Open to Test
New aliasing dereferening code is now available for testing on the OPENLDAP_REL_ENG_1_2 branch (available via CVS) which should resolve the crash condition you observed. cross backend aliases, however, are not supported. Kurt
changed notes changed state Test to Release
changed notes changed state Release to Closed
crash fix committed to devel/re1.2. released with 1.2.0. User should submit new ITS for cross backend aliasing.