- openldap-bugs - openldap.org

Re: ITS#4976 test008 crash with -lmcheck
by hyc＠symas.com 06 Oct '07

06 Oct '07

hyc(a)symas.com wrote: > I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence > with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no > such error occurs there. > > Also this report (which it seems the original is no longer accessible) implies > the same problem with mcheck > > http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… > Eh... Looking at glibc's mcheck code http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc shows that it has no mutex protection at all. It is completely invalid here, this ITS will be closed. -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 06 Oct '07

06 Oct '07

Aaron Richton wrote: > With that said, "some admin specifically disturbed the log files around > that time." Logs show that I was the only person in a position to do so > (unless somebody broke in and covered their tracks; we'll ignore that > theoretical possibility). On September 24, I reconfigured the slaves to > use a different IP address to the master instead of the existing > connection. The times are too coincidental to be unrelated: > > (slave4) reconfigured Sep 24 09:41 (first syslog complaint 09:43) > (slave6) reconfigured Sep 24 09:39 (first syslog complaint 09:44) > > > So...is there something that's cued off the (reverse?) name service > entries for the master? Does the master IP hash in to a CSN somehow? And > if this is indeed the case/root cause...well, quite honestly, I think that > assuming a name service database will remain constant throughout a slapd > instance is a fallacy. Furthermore, if this is indeed the case, it should > be absolutely trivial for me to reproduce this (I can perform a DR on > slave4/6, and reconfigure their network again). No. The BDB transaction log files don't know (or care) anything about IP addresses. Nothing at the slapd layer could have any direct effect on the BDB transaction logs. How exactly did you reconfigure the servers, did you stop them and restart them or did you use cn=config? > > With that in mind, I'll likely test this reproduction early next week. I > can still get db_stat from all slaves (working and not) at this point if > that's interesting. Comments? > Might as well get the db_stat -l output for a few of them to compare. -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 06 Oct '07

06 Oct '07

> Have you got backups from just before these occurrences? Can you see what the > last valid transaction log files were before this? Or perhaps you can get > some db_stat's off any other slaves that are still running OK? The idea is to > see whether the current valid CSNs on an equivalent slave are anywhere near > the numbers being logged here, e.g. 1/188113 or 1/8730339. > > Have you actually run out of disk space on the partitions holding the logs? > It's rather suspicious that two machines would act up at the same time unless > some admin specifically disturbed the log files on those two systems at > around that time. I don't have backups for slave bdb logs. The master slapcat output is considered sacred data; the slave bdb log files are considered derivable thereof and don't get backed up (we'd sooner just replace the entire slave if it acts up). The odds of the partitions filling is minimal; Solaris has that logged at kern.notice (which on our configuration is serious enough to mean a write to NVRAM), and logs that extend prior to September 24 don't show any such messages. With that said, "some admin specifically disturbed the log files around that time." Logs show that I was the only person in a position to do so (unless somebody broke in and covered their tracks; we'll ignore that theoretical possibility). On September 24, I reconfigured the slaves to use a different IP address to the master instead of the existing connection. The times are too coincidental to be unrelated: (slave4) reconfigured Sep 24 09:41 (first syslog complaint 09:43) (slave6) reconfigured Sep 24 09:39 (first syslog complaint 09:44) So...is there something that's cued off the (reverse?) name service entries for the master? Does the master IP hash in to a CSN somehow? And if this is indeed the case/root cause...well, quite honestly, I think that assuming a name service database will remain constant throughout a slapd instance is a fallacy. Furthermore, if this is indeed the case, it should be absolutely trivial for me to reproduce this (I can perform a DR on slave4/6, and reconfigure their network again). With that in mind, I'll likely test this reproduction early next week. I can still get db_stat from all slaves (working and not) at this point if that's interesting. Comments?

1 0

ITS#4976 test008 crash with -lmcheck
by hyc＠symas.com 06 Oct '07

06 Oct '07

I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no such error occurs there. Also this report (which it seems the original is no longer accessible) implies the same problem with mcheck http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 06 Oct '07

06 Oct '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.38 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.196.250.105) > > > Just noticed that my syslog files were growing faster than usual. Upon further > inspection, two slaves have multiple hdb databases corrupt. Both slave{4,6} have > been (and are) running slapd since September 4. All are running patched BDB > 4.2.52 (same binaries I've been using throughout the whole 2.3 series). All > DB_CONFIGs have DB_LOG_AUTOREMOVE set. Messages similar to below are spewing out > every checkpoint interval, which is the root cause of my logs growing unusually. > I'm inclined to just zap all the databases and start again (they're only > slaves), but figured I'd post for tracking and to ask if there's anything that > can be grabbed out of the running process before I do so. Curiously enough, > base4 only corrupted on slave4, not slave6. Additionally, there are other > databases hosted on each slave that appear unaffected. Have you got backups from just before these occurrences? Can you see what the last valid transaction log files were before this? Or perhaps you can get some db_stat's off any other slaves that are still running OK? The idea is to see whether the current valid CSNs on an equivalent slave are anywhere near the numbers being logged here, e.g. 1/188113 or 1/8730339. Have you actually run out of disk space on the partitions holding the logs? It's rather suspicious that two machines would act up at the same time unless some admin specifically disturbed the log files on those two systems at around that time. > > > The first indication of trouble: > > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base1): DB_ENV->log_flush: LSN of 1/8730339 past current end-of-log of > 1/188113 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base1): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base1): entryCSN.bdb: unable to flush page: 0 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base1): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base2): DB_ENV->log_flush: LSN of 54/1636114 past current end-of-log of > 4/2981780 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base2): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base2): entryUUID.bdb: unable to flush page: 0 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base2): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base3): DB_ENV->log_flush: LSN of 1/600564 past current end-of-log of 1/662 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base3): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base3): cn.bdb: unable to flush page: 0 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base3): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base4): DB_ENV->log_flush: LSN of 3/2765493 past current end-of-log of > 1/539 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base4): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base4): uid.bdb: unable to flush page: 0 > Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] > bdb(base4): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base1): DB_ENV->log_flush: LSN of 1/8730401 past current end-of-log of > 1/188113 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base1): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base1): entryCSN.bdb: unable to flush page: 0 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base1): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base2): DB_ENV->log_flush: LSN of 54/1634334 past current end-of-log of > 4/1649467 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base2): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base2): entryUUID.bdb: unable to flush page: 0 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base2): txn_checkpoint: failed to flush the buffer cache Invalid argument > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base3): DB_ENV->log_flush: LSN of 1/600564 past current end-of-log of 1/538 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base3): Database environment corrupt; the wrong log files may have been > removed or incompatible database files imported from another environment > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base3): cn.bdb: unable to flush page: 0 > Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] > bdb(base3): txn_checkpoint: failed to flush the buffer cache Invalid argument -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 06 Oct '07

06 Oct '07

Full_Name: Aaron Richton Version: 2.3.38 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.196.250.105) Just noticed that my syslog files were growing faster than usual. Upon further inspection, two slaves have multiple hdb databases corrupt. Both slave{4,6} have been (and are) running slapd since September 4. All are running patched BDB 4.2.52 (same binaries I've been using throughout the whole 2.3 series). All DB_CONFIGs have DB_LOG_AUTOREMOVE set. Messages similar to below are spewing out every checkpoint interval, which is the root cause of my logs growing unusually. I'm inclined to just zap all the databases and start again (they're only slaves), but figured I'd post for tracking and to ask if there's anything that can be grabbed out of the running process before I do so. Curiously enough, base4 only corrupted on slave4, not slave6. Additionally, there are other databases hosted on each slave that appear unaffected. The first indication of trouble: Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base1): DB_ENV->log_flush: LSN of 1/8730339 past current end-of-log of 1/188113 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base1): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base1): entryCSN.bdb: unable to flush page: 0 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base1): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base2): DB_ENV->log_flush: LSN of 54/1636114 past current end-of-log of 4/2981780 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base2): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base2): entryUUID.bdb: unable to flush page: 0 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base2): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base3): DB_ENV->log_flush: LSN of 1/600564 past current end-of-log of 1/662 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base3): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base3): cn.bdb: unable to flush page: 0 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base3): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base4): DB_ENV->log_flush: LSN of 3/2765493 past current end-of-log of 1/539 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base4): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base4): uid.bdb: unable to flush page: 0 Sep 24 09:43:36 slave4.rutgers.edu slapd[295]: [ID 446079 local4.debug] bdb(base4): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base1): DB_ENV->log_flush: LSN of 1/8730401 past current end-of-log of 1/188113 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base1): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base1): entryCSN.bdb: unable to flush page: 0 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base1): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base2): DB_ENV->log_flush: LSN of 54/1634334 past current end-of-log of 4/1649467 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base2): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base2): entryUUID.bdb: unable to flush page: 0 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base2): txn_checkpoint: failed to flush the buffer cache Invalid argument Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base3): DB_ENV->log_flush: LSN of 1/600564 past current end-of-log of 1/538 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base3): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base3): cn.bdb: unable to flush page: 0 Sep 24 09:44:49 slave6.rutgers.edu slapd[301]: [ID 446079 local4.debug] bdb(base3): txn_checkpoint: failed to flush the buffer cache Invalid argument

1 0

ITS#3864 SASL_SSF_EXTERNAL
by hyc＠symas.com 06 Oct '07

06 Oct '07

The code now copies to a sasl_ssf_t wherever necessary. The ldap_set_option() argument remains a (ber_len_t *) since that was probably the expected behavior. Of course, since we officially dropped support for Cyrus 1.x in 2003, it doesn't seem fair to consider that case here. Could go either way here. Thus far it hasn't been an issue on any known platform, 32 or 64 bit, so which way we decide to go doesn't much matter to me. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#4302 slapi_send_ldap_result and controls
by hyc＠symas.com 06 Oct '07

06 Oct '07

Again, works for me in 2.3.12. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#4244 SLAPI_ADD_RESCONTROL in prebind plugin
by hyc＠symas.com 06 Oct '07

06 Oct '07

Well, a bit late, but I could not reproduce this problem in 2.3.12. It looks like SLAPI_ADD_RESCONTROL was fixed on 2004/03/02, long before release 2.3.12. Anyway, your sample plugin works perfectly fine on my 2.3.12 build, after typos are fixed to get the plugin to compile. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Bus Error - core dumped (ITS#5162)
by piotr.tarnowski＠us.edu.pl 05 Oct '07

05 Oct '07

Howard Chu pisze: > > BDB versions newer than 4.6.3 are not supported by OpenLDAP 2.3. There's > no bug here. Where can I read about supported versions ? I didn't find this information. In README file I found this: SLAPD: BDB and HDB backends require Sleepycat Berkeley DB 4.2 or later Also in requirements there is no such information. Thanks for your help, with BerkeleyDB 4.5.20 tests passed. Regards -- Piotr (DrFugazi) Tarnowski University of Silesia Katowice, Poland

1 0

Re: [JunkMail] Re: Bus Error - core dumped (ITS#5162)
by hyc＠symas.com 05 Oct '07

05 Oct '07

piotr.tarnowski(a)us.edu.pl wrote: > Excuse me, but I don't know gdb, then if you want more informations, you > should write me exact instructions what should I do to collect them. > > BTW: I think this is a problem with BerkeleyDB.4.6, then I compiled > OpenLDAP with BerkeleyDB.4.5.20, and now this test passed (others too, > for now). BDB versions newer than 4.6.3 are not supported by OpenLDAP 2.3. There's no bug here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Bus Error - core dumped (ITS#5162)
by piotr.tarnowski＠us.edu.pl 05 Oct '07

05 Oct '07

Gavin Henry wrote: > Can we have your configure options and Berkeley versions etc. Hello, there are my flags and options: CFLAGS="-fast -xautopar -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include -I/usr/sfw/inc lude" MAKE=gmake PARALLEL=2 CXX=CC CXXFLAGS=$CFLAGS CPPFLAGS=$CFLAGS LDFLAGS="-xautopar -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -R/usr/local/BerkeleyDB.4.6 /lib -L/usr/local/lib -R/usr/local/lib -L/usr/sfw/lib -R/usr/sfw/lib" KATALOG=openldap-2.3.38 KAT=openldap --- ./configure \ --prefix=/usr/local/$KATALOG \ --infodir=/usr/local/info --mandir=/usr/local/man \ --sysconfdir=/data/etc/$KAT \ --localstatedir=/data/var/$KAT \ --enable-slapd --enable-crypt --enable-lmpasswd \ --enable-modules --enable-wrappers \ --disable-sql \ --enable-accesslog=mod \ --enable-lastmod=mod \ --enable-slurpd \ --enable-dynamic \ --without-cyrus-sasl \ --enable-backends=mod \ --disable-shell --- OpenLDAP version 2.3.38 (openldap-stable-20070831.tgz) BerkeleyDB version 4.6.21 (with 4.6.19 the same) System and compiler: % uname -a SunOS hostname 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V890 % version Machine hardware: sun4u OS version: 5.10 Processor type: sparc Hardware: SUNW,Sun-Fire-V890 The following components are installed on your system: Sun Studio 12 Sun Studio 12 C Compiler Sun Studio 12 C++ Compiler Sun Studio 12 Tools.h++ 7.1 Sun Studio 12 C++ Standard 64-bit Class Library Sun Studio 12 Garbage Collector Sun Studio 12 Fortran 95 Sun Studio 12 Debugging Tools (including dbx) Sun Studio 12 IDE Sun Studio 12 Debugger GUI Sun Studio 12 Performance Analyzer (including collect, ...) Sun Studio 12 X-Designer Sun Studio 12 VIM editor Sun Studio 12 XEmacs editor Sun Studio 12 Performance Library Sun Studio 12 LockLint Sun Studio 12 Building Software (including dmake) Sun Studio 12 Documentation Set Sun Studio 12 /usr symbolic links and GNOME menu item version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc Patch 127000-01 2007/07/18 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc Patch 124872-02 2007/08/16 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19 --- Dump: % /opt/csw/bin/gdb /soft/openldap/openldap-2.3.38/servers/slapd/.libs/slapd core GNU gdb 6.6 Copyright (C) 2006 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 "sparc-sun-solaris2.8"... Reading symbols from /soft/openldap/openldap-2.3.38/libraries/libldap_r/.libs/libldap_r-2.3.so.0...done. Loaded symbols for /soft/openldap/openldap-2.3.38/libraries/libldap_r/.libs/libldap_r-2.3.so.0 Reading symbols from /soft/openldap/openldap-2.3.38/libraries/liblber/.libs/liblber-2.3.so.0...done. Loaded symbols for /soft/openldap/openldap-2.3.38/libraries/liblber/.libs/liblber-2.3.so.0 Reading symbols from /usr/local/lib/libltdl.so.3...done. Loaded symbols for /usr/local/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.1... warning: Lowest section in /lib/libdl.so.1 is .hash at 000000b4 done. Loaded symbols for /lib/libdl.so.1 Reading symbols from /usr/local/openssl-0.9.8e/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/ssl/lib/libssl.so.0.9.8 Reading symbols from /usr/local/openssl-0.9.8e/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/local/ssl/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libgen.so.1...done. Loaded symbols for /lib/libgen.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libsocket.so.1...done. Loaded symbols for /lib/libsocket.so.1 Reading symbols from /usr/sfw/lib/libwrap.so.1...done. Loaded symbols for /usr/sfw/lib/libwrap.so.1 Reading symbols from /lib/libmtsk.so.1...done. Loaded symbols for /lib/libmtsk.so.1 Reading symbols from /lib/libthread.so.1... warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000074 done. Loaded symbols for /lib/libthread.so.1 Reading symbols from /lib/libc.so.1...done. Loaded symbols for /lib/libc.so.1 Reading symbols from /lib/libm.so.2...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /lib/libpthread.so.1... warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074 done. Loaded symbols for /lib/libpthread.so.1 Reading symbols from /platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1...done. Loaded symbols for /platform/SUNW,Sun-Fire-V890/lib/libc_psr.so.1 Reading symbols from /usr/lib/locale/pl_PL.UTF-8/pl_PL.UTF-8.so.3...done. Loaded symbols for /usr/lib/locale/pl_PL.UTF-8/pl_PL.UTF-8.so.3 Reading symbols from /usr/lib/locale/common/methods_unicode.so.3...done. Loaded symbols for /usr/lib/locale/common/methods_unicode.so.3 Reading symbols from /lib/libmp.so.2...done. Loaded symbols for /lib/libmp.so.2 Reading symbols from /lib/libmd.so.1...done. Loaded symbols for /lib/libmd.so.1 Reading symbols from /lib/libscf.so.1...done. Loaded symbols for /lib/libscf.so.1 Reading symbols from /lib/libdoor.so.1...done. Loaded symbols for /lib/libdoor.so.1 Reading symbols from /lib/libuutil.so.1...done. Loaded symbols for /lib/libuutil.so.1 Reading symbols from /usr/lib/nss_cluster.so.1...done. Loaded symbols for /usr/lib/nss_cluster.so.1 Reading symbols from /usr/cluster/lib/libclos.so.1...done. Loaded symbols for /usr/cluster/lib/libclos.so.1 Reading symbols from /usr/cluster/lib/libscprivip.so.1...done. Loaded symbols for /usr/cluster/lib/libscprivip.so.1 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libsecdb.so.1...done. Loaded symbols for /lib/libsecdb.so.1 Reading symbols from /usr/lib/libCstd.so.1...done. Loaded symbols for /usr/lib/libCstd.so.1 Reading symbols from /usr/lib/libCrun.so.1...done. Loaded symbols for /usr/lib/libCrun.so.1 Reading symbols from /usr/cluster/lib/libclcomm.so.1...done. Loaded symbols for /usr/cluster/lib/libclcomm.so.1 Reading symbols from /usr/cluster/lib/libclconf.so.1...done. Loaded symbols for /usr/cluster/lib/libclconf.so.1 Reading symbols from /lib/libaio.so.1...done. Loaded symbols for /lib/libaio.so.1 Reading symbols from /lib/libcmd.so.1...done. Loaded symbols for /lib/libcmd.so.1 Reading symbols from /lib/libmd5.so.1... warning: Lowest section in /lib/libmd5.so.1 is .dynamic at 00000074 done. Loaded symbols for /lib/libmd5.so.1 Reading symbols from /usr/lib/cpu/sparcv8plus/libCstd_isa.so.1...done. Loaded symbols for /usr/lib/cpu/sparcv8plus/libCstd_isa.so.1 Reading symbols from /lib/nss_files.so.1...done. Loaded symbols for /lib/nss_files.so.1 Reading symbols from /soft/openldap/openldap-2.3.38/servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0...done. Loaded symbols for ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 Reading symbols from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so Reading symbols from /soft/openldap/openldap-2.3.38/servers/slapd/back-monitor/.libs/back_monitor-2.3.so.0...done. Loaded symbols for ../servers/slapd/back-monitor/.libs/back_monitor-2.3.so.0 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 Core was generated by `/soft/openldap/openldap-2.3.38/servers/slapd/.libs/slapd -s0 -f ./testrun/slapd'. Program terminated with signal 10, Bus error. #0 0xfdf2b510 in __lock_get_internal () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so (gdb) bt full #0 0xfdf2b510 in __lock_get_internal () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #1 0xfdf2ae04 in __lock_get () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #2 0xfdf6cf48 in __db_lget () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #3 0xfdead994 in __bam_get_root () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #4 0xfdeadd84 in __bam_search () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #5 0xfde9b5dc in __bamc_search () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #6 0xfde97418 in __bamc_get () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #7 0xfdf5776c in __dbc_get () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #8 0xfdf67d64 in __dbc_get_pp () from /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.so No symbol table info available. #9 0xfe04bd2c in bdb_id2entry () from ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 No symbol table info available. #10 0xfe051460 in bdb_cache_find_id () from ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 No symbol table info available. #11 0xfe049d88 in bdb_dn2entry () from ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 No symbol table info available. #12 0xfe041264 in bdb_search () from ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 No symbol table info available. #13 0xfe041264 in bdb_search () from ../servers/slapd/back-bdb/.libs/back_bdb-2.3.so.0 No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) --- Excuse me, but I don't know gdb, then if you want more informations, you should write me exact instructions what should I do to collect them. BTW: I think this is a problem with BerkeleyDB.4.6, then I compiled OpenLDAP with BerkeleyDB.4.5.20, and now this test passed (others too, for now). Regards -- Piotr (DrFugazi) Tarnowski University of Silesia Katowice, Poland

1 0

No replication after power failure
by Stelios Grigoriadis 05 Oct '07

05 Oct '07

I am not sure this would be considered a bug, but it is a problem for us. If the master goes down, the replicas have no way of detecting it. When the master is going back up again, all replica servers have to be restarted. Is there a way to avoid this? Using the KEEPALIVE option (socket or TCP) is not really an option since the default timeout is 2 hours which is too long. Another would be to have some kind of timeout in the epoll and check if the master is responding, but that timeout is used for the runqueue? Have you come across this? I was surprised to see that no one has had any issues with it. Am I missing something? Regards /Stelios Grigoriadis

3 4

Re: (ITS#5169) Test0001 - segmentation fault - slapd
by quanah＠zimbra.com 05 Oct '07

05 Oct '07

--On Friday, October 05, 2007 9:03 AM +0000 andy.n.parker(a)unilever.com wrote: > Full_Name: Andrew N Parker > Version: 2.3.38 > OS: RHEL 4.2 32 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.60.106.5) OpenLDAP 2.3.38 does not support BDB 4.6. Use a supported BDB release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5170) Issue with mirrormode: endless loop when multiple add/delete
by hyc＠symas.com 05 Oct '07

05 Oct '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There was an issue with mirror mode, which caused an endless replication loop > when repeated, very close add/delete of the same object, like those performed by > the slapd-addel tester tool, were performed in a multimaster environment using > refreahAndPersist. > > Howard fixed this by letting syncrepl_entry() propagate the replication cookie, > if available, so that modifications don't get sent back to the SID that > generated them (please correct me if I got it wrong). The same issue is > probably affecting cascaded syncrepl, but not delta-syncrepl. Right, refreshAndPersist in a cascaded syncrepl would also be affected by the patch, although so far there's no indication that this caused any actual problems. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5170) Issue with mirrormode: endless loop when multiple add/delete
by ando＠sys-net.it 05 Oct '07

05 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando There was an issue with mirror mode, which caused an endless replication loop when repeated, very close add/delete of the same object, like those performed by the slapd-addel tester tool, were performed in a multimaster environment using refreahAndPersist. Howard fixed this by letting syncrepl_entry() propagate the replication cookie, if available, so that modifications don't get sent back to the SID that generated them (please correct me if I got it wrong). The same issue is probably affecting cascaded syncrepl, but not delta-syncrepl. p.

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by ando＠sys-net.it 05 Oct '07

05 Oct '07

hyc(a)symas.com wrote: > Except that from ITS#5070 we always use hex for serial numbers now, so this > would actually be > { > serialNumber '03'H, > issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, > c=us" > } works for me... 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

Howard Chu wrote: > I.e., the sequence should be enclosed in double quotes. So your example should be > > { > serialNumber 3, > issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, > c=us" > } Except that from ITS#5070 we always use hex for serial numbers now, so this would actually be { serialNumber '03'H, issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, c=us" } -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5169) Test0001 - segmentation fault - slapd
by andy.n.parker＠unilever.com 05 Oct '07

05 Oct '07

Full_Name: Andrew N Parker Version: 2.3.38 OS: RHEL 4.2 32 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) Running the standard installtion script; make test. tes001-slapadd fails with a segmentation fault from slapd. Compiled with OpenSSl 0.9.8e & BerkeleyDB 4.6.19. O/S RHEL 4.2, hardware Intel (arch command gives string i686). The same software combination seems to work on RHEL 4.2 64 bit. Here is the stack trace: <<< dnPrettyNormal: <cn=Start,cn=Time,cn=Monitor>, <cn=start,cn=time,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Start,cn=Time,cn=Monitor) -> 0x97dc658 => str2entry: "dn: cn=Current,cn=Time,cn=Monitor objectClass: monitoredObject structuralObjectClass: monitoredObject cn: Current monitorTimestamp: 20071004185030Z creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Current,cn=Time,cn=Monitor> <<< dnPrettyNormal: <cn=Current,cn=Time,cn=Monitor>, <cn=current,cn=time,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Current,cn=Time,cn=Monitor) -> 0x97dca60 => str2entry: "dn: cn=Read,cn=Waiters,cn=Monitor objectClass: monitorCounterObject structuralObjectClass: monitorCounterObject cn: Read creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Read,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Read,cn=Waiters,cn=Monitor>, <cn=read,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Read,cn=Waiters,cn=Monitor) -> 0x97dce70 => str2entry: "dn: cn=Write,cn=Waiters,cn=Monitor objectClass: monitorCounterObject structuralObjectClass: monitorCounterObject cn: Write creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor>, <cn=write,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Write,cn=Waiters,cn=Monitor) -> 0x97dd580 slapd starting [New Thread 26901424 (LWP 9269)] >>> slap_listener(ldap://localhost:9011) connection_get(14): got connid=0 connection_read(14): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: [New Thread 128756656 (LWP 9285)] ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 14 do_bind: v3 anonymous bind connection_get(14): got connid=0 connection_read(14): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 54 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=example,dc=com> <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=0 op=1 dn="[anonymous]" => bdb_search bdb_dn2entry("dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: got id=0x00000001 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 128756656 (LWP 9285)] 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so (gdb) bt full #0 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #1 0x006fc6eb in __lock_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #2 0x00731ea9 in __db_lget () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #3 0x006a6316 in __bam_get_root () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #4 0x006a6633 in __bam_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #5 0x00698d70 in __bamc_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #6 0x00699f3c in __bamc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #7 0x007244b4 in __dbc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #8 0x0072efb2 in __dbc_get_pp () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #9 0x080de047 in bdb_id2entry (be=0x69, tid=0x0, locker=26, id=1, e=0x7a08e1c) at id2entry.c:125 bdb = (struct bdb_info *) 0x97780c0 db = (DB *) 0x97c9ce8 key = {data = 0x7a08d7c, size = 4, ulen = 0, dlen = 0, doff = 0, ---Type <return> to continue, or q <return> to quit--- app_data = 0x0, flags = 4} data = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 8} cursor = (DBC *) 0x97cae48 bv = {bv_len = 0, bv_val = 0x182 <Address 0x182 out of bounds>} rc = 0 nid = 16777216 #10 0x080d7d39 in bdb_cache_find_id (op=0x97ded30, tid=0x0, id=1, eip=0x7a08ea8, islocked=0, locker=26, lock=0x7a09080) at cache.c:760 bdb = (struct bdb_info *) 0x97780c0 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 1, bei_lockpad = 0 '\0', bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #11 0x080db009 in bdb_dn2entry (op=0x97ded30, tid=0x0, dn=0x97ded4c, e=0x7a08fc8, matched=1, locker=26, lock=0x7a09080) at dn2entry.c:68 ei = (EntryInfo *) 0x97defc0 rc = 0 rc2 = Variable "rc2" is not available. (gdb) thread apply all bt Thread 3 (Thread 128756656 (LWP 9285)): #0 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #1 0x006fc6eb in __lock_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #2 0x00731ea9 in __db_lget () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #3 0x006a6316 in __bam_get_root () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #4 0x006a6633 in __bam_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #5 0x00698d70 in __bamc_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #6 0x00699f3c in __bamc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #7 0x007244b4 in __dbc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #8 0x0072efb2 in __dbc_get_pp () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #9 0x080de047 in bdb_id2entry (be=0x69, tid=0x0, locker=26, id=1, e=0x7a08e1c) at id2entry.c:125 #10 0x080d7d39 in bdb_cache_find_id (op=0x97ded30, tid=0x0, id=1, eip=0x7a08ea8, islocked=0, locker=26, lock=0x7a09080) at cache.c:760 #11 0x080db009 in bdb_dn2entry (op=0x97ded30, tid=0x0, dn=0x97ded4c, e=0x7a08fc8, matched=1, locker=26, lock=0x7a09080) at dn2entry.c:68 #12 0x080c6439 in bdb_search (op=0x97ded30, rs=0x7aca220) at search.c:374 #13 0x0806fc6a in fe_op_search (op=0x97ded30, rs=0x7aca220) at search.c:355 #14 0x0806f569 in do_search (op=0x97ded30, rs=0x7aca220) at search.c:217 #15 0x0806e058 in connection_operation (ctx=0x7aca2b0, arg_v=0x97ded30) at connection.c:1133 #16 0x00f787fb in ldap_int_thread_pool_wrapper (xpool=0x9752020) ---Type <return> to continue, or q <return> to quit--- at tpool.c:478 #17 0x00ae9341 in start_thread () from /lib/tls/libpthread.so.0 #18 0x00a546fe in clone () from /lib/tls/libc.so.6 Thread 2 (Thread 26901424 (LWP 9269)): #0 0x009747a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00a54d7e in epoll_wait () from /lib/tls/libc.so.6 #2 0x0806a5a7 in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #3 0x00ae9341 in start_thread () from /lib/tls/libpthread.so.0 #4 0x00a546fe in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -1208018720 (LWP 9266)): #0 0x009747a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00aea06d in pthread_join () from /lib/tls/libpthread.so.0 #2 0x00f79202 in ldap_pvt_thread_join (thread=26901424, thread_return=0x0) at thr_posix.c:193 #3 0x0806bb45 in slapd_daemon () at daemon.c:2579 #4 0x0805ccb7 in main (argc=8, argv=0xbfeff084) at main.c:859 Here is the output from the test run (I had to modify it slightly to get the gdb output): description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. creatorsName: modifiersName: createTimestamp: 20071004182607Z modifyTimestamp: 20071004182607Z monitoredInfo: OpenLDAP: slapd 2.3.38 (Oct 4 2007 17:10:33) entryDN: cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE >>>>> Test succeeded >>>>> ./scripts/test000-rootdse completed OK. >>>>> waiting 10 seconds for things to exit >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... ../servers/slapd/slapd -s0 -f ./testrun/slapd.1.conf -h ldap://localhost:9011/ -d 1 (The above line is an echo of the script line) (read statement in here) (Now I start gdb etc and run your slapd in the tests area). Using ldapsearch to retrieve all the entries... /tmp/openldap-2.3.38/tests ../clients/tools/ldapsearch -P 3 -x -LLL ./testrun/ldapsearch.out Now I obtain the failure in gdb. I can repeat this. Here is my build script: export CPPFLAGS="-I/usr/local/openssl098e/include -I/usr/kerberos/include -I/usr/local/berkeleydb4619/include" export LDFLAGS="-L/usr/lib -L/lib -L/lib/tls -L/usr/local/openssl098e/lib -L/usr/local/berkeleydb4619/lib" export LD_LIBRARY_PATH="/usr/local/berkeleydb4619/lib;/usr/local/openssl098e/lib" StdMsg -i "OpenLDAP - Running configure: CPPFLAGS=${CPPFLAGS}." StdMsg -i "OpenLDAP - Running configure: LDFLAGS=${LDFLAGS}." StdMsg -i "OpenLDAP - Running configure: LD_LIBRARY_PATH=${LD_LIBRARY_PATH}." ./configure \ --x-includes=/usr/include \ --x-includes=/usr/include/openssl/ssl \ --x-includes=/usr/include/openssl \ --x-libraries=/usr/lib \ --x-libraries=/lib \ --x-libraries=/lib/tls \ --prefix=${TARGET} \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-ipv6 \ --enable-local \ --with-cyrus-sasl \ --with-threads \ --with-tls \ --with-yielding-select \ --enable-overlays \ --enable-slapd \ --enable-slapi \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-lmpasswd \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-rlookups \ --enable-wrappers \ --enable-bdb \ --enable-dnssrv=mod \ --enable-ldap \ --enable-passwd=mod \ --enable-perl=mod \ --enable-shell=mod \ --enable-dyngroup \ --enable-proxycache \ --enable-slurpd \ --enable-hdb=mod \ --enable-ldbm=mod \ --enable-ldbm-api=auto \ --enable-ldbm-type=auto \ --enable-meta=mod \ --enable-null=mod \ --enable-static \ --enable-shared | \ tee -a $Log_File If you need more info, just ask. Andrew N Parker

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Yes, it looks like we're using an invalid format for the issuer component. >> Seems like using the GSER format is a bit harder to parse, since we have no >> reliable indicator of where the rdnSequence ends. Any thoughts? > > In general, I agree. In this specific case, it ends at the end of the > octetString :) I take that back. Section 3.20 of RFC3641 says >>> 3.20. Variant Encodings The values of some named complex ASN.1 types have special string encodings. These special encodings are always used instead of the encoding that would otherwise apply based on the ASN.1 type definition. VariantEncoding = RDNSequenceValue / RelativeDistinguishedNameValue / ORAddressValue A value of the RDNSequence type, i.e., a distinguished name, is encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN character string. The character string is first derived according to the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value, i.e., between double quotes with any embedded double quotes escaped by being repeated. <<< I.e., the sequence should be enclosed in double quotes. So your example should be { serialNumber 3, issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, c=us" } -- -- Howard Chu Chief Architect, 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#5072 incorrect certificateExactAssertion()
by ando＠sys-net.it 05 Oct '07

05 Oct '07

hyc(a)symas.com wrote: > Yes, it looks like we're using an invalid format for the issuer component. > Seems like using the GSER format is a bit harder to parse, since we have no > reliable indicator of where the rdnSequence ends. Any thoughts? In general, I agree. In this specific case, it ends at the end of the octetString :) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

Yes, it looks like we're using an invalid format for the issuer component. Seems like using the GSER format is a bit harder to parse, since we have no reliable indicator of where the rdnSequence ends. Any thoughts? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5168) slapo-rwm(5) does not handle UUID syntax attrs in seach filters
by ando＠sys-net.it 04 Oct '07

04 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I found out that most of the issues I was seeing with syncrepl were a (nasty) side-effect of the fact that slapo-rwm does not play well with UUID-syntax attrs in search filters; unfortunately, syncrepl heavily exploits searching with equality filters on entryUUID... fixed. PS: sorry for the noise.

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 04 Oct '07

04 Oct '07

Well, well. Forgive me for saying that now you're beeing a little narrow minded. If programs that belong to software like openldap (such as slapadd) do 'setuid()' themselves then end users (and administrators): - Need to remember (or know) less things; - Need to type less; - Have fewer chances to break the working state of stuff, which in turn spares people time (Google'ing, Bug reports, your response, etc.) Not that I'm saying that life is easy, but shouldn't we try to bring ease to life if we can? From this K.I.S.S. point-of-view is wildly guessed that slapadd not setuid'ing was a bug. If you wish to prevent future events for other users, you should consider this a bug. I won't bother you again. I'll just 'chown openlpad:openldap /usr/sbin/slapadd' and then 'chmod a+s /usr/sbin/slapadd' as it should be more than enough to avoid future events for me. Thank your time and promptly reply. I don't know if you get payd for doing this stuff, but you should. Starting in November Google for 'science ,not fiction'. Thanks again. Pedro RA Pierangelo Masarati escreveu: > pedrorandrade(a)gmail.com wrote: > > >> One workaround is issuing 'sudo -u openldap slapadd ...' to avoid >> chown'ing afterwards. >> > > What you call a workaround is actually The Right Thing (TM). There is > no way to setuid() tools simply because there's no need to, as they can > be run with the right identity. The only reason slapd can be setuid() > is that it needs to start as root in order to bind to port 389, and > **then** setuid() before doing anything else. Running programs as the > correct user is normal UNIX administration - or should OpenLDAP also > document ls, rm, ...? > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

ITS#5166
by ando＠sys-net.it 04 Oct '07

04 Oct '07

I've added a comment in slapadd(8), slapindex(8) about the need to make sure commands are either executed with the right identity, or their ownership is changed after execution. As a side note, if any of the tools that access the database (slapacl, slapauth, slapcat, slaptest without -u) are run with an empty environment, they'll create the environment, of course owned by the identity they've been run as. This is a known problem; they should rather refuse to operate if the environment is empty, since they need an already set up one. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs