- openldap-bugs - openldap.org

(ITS#5172) slash in dn
by reinhold.may＠gmx.de 07 Oct '07

07 Oct '07

Full_Name: Reinhold May Version: 2.3.35 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.216.115.71) I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that case: sorry. I've been trying to import the following .ldif: dn: dc=somedomain,dc=org objectclass: top objectclass: dcObject objectclass: organization o: somedomain LDAP dc: somedomain dn: ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: My address book dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: Medical dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: With/Slash sn: With/Slash The "/" results into the following error message: ldap_add: No such object (32) additional info: Parent does not exist If my last entry reads: dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: WithoutSlash sn: WithoutSlash slapd accepts the entry and adds it to its directory. I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to be a special character. But just in case it was forgotten, I tried to represent it as "\/" and "\2f" but neither solution helped.

1 0

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

07 Oct '07

> 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? echo 192.blahblah master.r.e >> /etc/hosts The master changed from 128.blahblah to 192.blahblah. Same physical machine, just different interface. On slave4 and 6, I didn't touch slapd. > Might as well get the db_stat -l output for a few of them to compare. This isn't going well at all; they just can't join the environment. I tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're talking >30 minutes here.) Although I swear I've run db_stat hot, I killed db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, ran db_stat again, and it hung there...and corrupted the environment to the point where I couldn't get db_recover/slapd to run. (I ended up blowing the slave1 database away; it's refreshing from syncrepl now.) I've got a few more slaves that I haven't shot in the foot yet, and I only tried this on one of the suffixes on slave{1,4}. Plenty of more opportunities to screw this up yet if there's anything to try...I suppose I could go for -N, or if the command line is going to be a pain, I could join the slapd process with dbx and print ->log_stat myself (although I might need a bit of hand holding on that)... [the hang on slave4] db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) lwp_mutex_lock(0xFF0D0000) (sleeping...) mutex type: USYNC_PROCESS ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 00011470 _start (0, 0, 0, 0, 0, 0) + 108

1 0

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

07 Oct '07

Howard Chu wrote: > 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. By the way, this stzck trace confirms the problem: (gdb) info thr 17 Thread 1208023360 (LWP 4680) 0x00002ae575308491 in clone () from /lib64/libc.so.6 16 Thread 1199630656 (LWP 4679) 0x00002ae575277535 in raise () from /lib64/libc.so.6 15 Thread 1191237952 (LWP 4678) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 * 14 Thread 1182845248 (LWP 4677) 0x00002ae5752bc3b7 in memset () from /lib64/libc.so.6 13 Thread 1174452544 (LWP 4676) 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 12 Thread 1166059840 (LWP 4675) 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 11 Thread 1157667136 (LWP 4674) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 10 Thread 1149274432 (LWP 4673) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 9 Thread 1140881728 (LWP 4672) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 8 Thread 1132489024 (LWP 4671) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 7 Thread 1124096320 (LWP 4670) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 6 Thread 1115703616 (LWP 4669) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 5 Thread 1107310912 (LWP 4665) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 4 Thread 1098918208 (LWP 4655) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 3 Thread 1090525504 (LWP 4650) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 2 Thread 1082132800 (LWP 4639) 0x00002ae5753088b8 in ?? () from /lib64/libc.so.6 1 Thread 47165004620160 (LWP 4632) 0x00002ae5746795d5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thr 13 [Switching to thread 13 (Thread 1174452544 (LWP 4676))]#0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 #1 0x00002ae5752b89b9 in mallochook () from /lib64/libc.so.6 #2 0x00002ae57410f865 in ber_memalloc_x (s=9297104, ctx=0x2ae57410f865) at ../../../head/libraries/liblber/memory.c:226 #3 0x00002ae57410fd68 in ber_dupbv_x (dst=0x46009b80, src=0x2aaaaadae240, ctx=0x0) at ../../../head/libraries/liblber/memory.c:501 #4 0x00002ae573ed26ce in ldap_bv2escaped_filter_value_x (in=0x2aaaaadae240, out=0x46009b80, inplace=0, ctx=0x933bd0) at search.c:468 #5 0x000000000043d239 in filter2bv_x (op=0x92e4c0, f=0x2aaaaadae280, fstr=0x92e538) at ../../../head/servers/slapd/filter.c:608 #6 0x000000000043a943 in do_search (op=0x92e4c0, rs=0x4600acb0) at ../../../head/servers/slapd/search.c:138 #7 0x0000000000437e5e in connection_operation (ctx=0x4600ade0, arg_v=0x92e4c0) at ../../../head/servers/slapd/connection.c:1145 #8 0x0000000000438332 in connection_read_thread (ctx=0x4600ade0, argv=0xb) at ../../../head/servers/slapd/connection.c:1271 #9 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #10 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () (gdb) thr 12 [Switching to thread 12 (Thread 1166059840 (LWP 4675))]#0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 #1 0x00002ae5752b8a36 in freehook () from /lib64/libc.so.6 #2 0x000000000045b93d in ch_free (ptr=0x7d9370) at ../../../head/servers/slapd/ch_malloc.c:139 #3 0x000000000049accd in slap_sasl_open (conn=0x2ae5769dbe60, reopen=<value optimized out>) at ../../../head/servers/slapd/sasl.c:1395 #4 0x00000000004368d9 in connection_init (s=18, listener=0x7a2ad0, dnsname=0x4efe78 "unknown", peername=0x45808ca0 "IP=127.0.0.1:36732", flags=0, ssf=0, authid=0x0, peerbv=0x45808c80) at ../../../head/servers/slapd/connection.c:633 #5 0x00000000004332e0 in slap_listener (sl=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1823 #6 0x0000000000433489 in slap_listener_thread (ctx=0x45809de0, ptr=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1856 #7 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #8 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) Note that thread 12 is removing a block from the chunk list while thread 13 is walking the list. There is absolutely no thread safety here whatsoever. -- -- 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#4976 test008 crash with -lmcheck
by hyc＠symas.com 07 Oct '07

07 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 07 Oct '07

07 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 07 Oct '07

07 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 07 Oct '07

07 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 07 Oct '07

07 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

(ITS#5167) Contribution of section for admin guide covering memberof overlay
by bgmilne＠staff.telkomsa.net 04 Oct '07

04 Oct '07

Full_Name: Buchan Milne Version: 2.4.5 OS: Linux URL: ftp://ftp.openldap.org/incoming/buchan-milne-20071004-2.patch Submission from: (NULL) (196.15.129.131) I wrote a short description and example of the use of the memberof overlay for use in the placeholder in the admin guide.

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by ando＠sys-net.it 04 Oct '07

04 Oct '07

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

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by rra＠stanford.edu 04 Oct '07

04 Oct '07

pedrorandrade(a)gmail.com writes: > After testing, I think the problem is with slapadd. > The above command (slapd -l base.ldif) created one 'objectClass.bdb' > file owned by root:root. > After chown'ing that bdb file all works again. > Furthermore, if one skips the slapd start/stop steps, slapadd populates > the database dir and all created files are owned by root. > Is this a bug or not? Shouldn't 'slapadd' setuid();? If you're going to run slapd as a non-root user, you need to be sure that all data initialization is done as the user you're running slapd as. If any of that data initialization is done by the Debian packaging scripts (the upgrade scripts, the init script, and so forth), that's a bug in the Debian package. Please submit a bug to Debian so that we can fix it there. I doubt that anything here is a bug in OpenLDAP. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

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

04 Oct '07

OK. Pierangelo Masarati is right all the way. I'm not using the latest release. I'm using the one that debian provides. C programming doesn't 'chroot's, it 'setuid();'s. My mistake. Sorry. I'm not into the internals of openldap, but Pierangelo sure is and setuid() **before** reading the configuration files makes sense (which reminds me i should 'chown' those too), so I was far off. But, one issue remains: When I deleted the files, /etc/init.d/slapd start /etc/init.d/slapd stop slapd -l base.ldif /etc/init.d/slapd start ldapdelete failed again with the same error: (80) entry index delete failed After testing, I think the problem is with slapadd. The above command (slapd -l base.ldif) created one 'objectClass.bdb' file owned by root:root. After chown'ing that bdb file all works again. Furthermore, if one skips the slapd start/stop steps, slapadd populates the database dir and all created files are owned by root. Is this a bug or not? Shouldn't 'slapadd' setuid();? One workaround is issuing 'sudo -u openldap slapadd ...' to avoid chown'ing afterwards. Oh, and yes Pierangelo, I make mistakes. Lots of them, unfortunately, like many users. But I try not to post them in Bug reports ;)

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by ando＠sys-net.it 03 Oct '07

03 Oct '07

pedrorandrade(a)gmail.com wrote: > Full_Name: Pedro RA > Version: 2.3.30-5 > OS: Debian 4.1.1-21 > URL: > Submission from: (NULL) (85.139.209.115) The latest release is 2.3.38. > When slapd is starting, and no database exists, slapd creates a new one with the > wrong permissions (user:root, group:root) > This probably is caused by slapd creating the database before chroot. Probably you mean before setuid(); chroot has nothing to do with the identity a process is running as. > The before-chroot creation of the database is the bug. The database is opened (and thus created, if it doesn't exist) only **after** setuid(). In fact, setuid() (and chroot() occur **before** even reading the configuration file. If it were like you say, the files would have been created **before** even knowing in which directory they should be located. > When this happens ldap-delete operations fail with: > ldap_delete: Internal (implementation specific) error (80) > additional info: entry index delete failed Probably you unintentionally performed some operation that created the files before starting slapd. 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) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 03 Oct '07

03 Oct '07

Full_Name: Pedro RA Version: 2.3.30-5 OS: Debian 4.1.1-21 URL: Submission from: (NULL) (85.139.209.115) When slapd is starting, and no database exists, slapd creates a new one with the wrong permissions (user:root, group:root) This probably is caused by slapd creating the database before chroot. The before-chroot creation of the database is the bug. When this happens ldap-delete operations fail with: ldap_delete: Internal (implementation specific) error (80) additional info: entry index delete failed A working workaround is setting the right permissions to DBD files. In my system (Debian Etch 4.1.1-21, openldap 2.3.30-5) the command is: chmod -r openldap:openldap /var/lib/ldap

1 0

Issues with syncrepl and mirrormode
by Pierangelo Masarati 03 Oct '07

03 Oct '07

We're experiencing some strange issues with mirrormode; I don't have the whole picture at hand, right now, and I haven't been able to create the issue in a repeatable manner, however it happens regularly. The scenario is: 2 mirror-mode servers, each with 2 databases, plus back-config, replicated using syncrepl refreshAndPersist. We notice occasional sigsegv, and we could finally get a core dump, which contains #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 665 for (j=0; !BER_BVISNULL( &sc2->ctxcsn[j] ); j++) { (gdb) bt full #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 i = 0 j = 0 match = 0 text = 0x80e0e1a "\201� #1 0x080e7385 in do_syncrep2 (op=0x33a96d40, si=0x919c548) at ../../../servers/slapd/syncrepl.c:990 i = Variable "i" is not available. (gdb) p *sc1 $2 = {ctxcsn = 0x9981310, octet_str = {bv_len = 60, bv_val = 0x9d2b680 "rid=004,sid=000,csn=20070925132254.897919Z#000000#000#000000"}, rid = 4, sid = 0, numcsns = 1, sids = 0x9ce3120, sc_next = {stqe_next = 0x0}} (gdb) p *sc2 $3 = {ctxcsn = 0x0, octet_str = {bv_len = 20, bv_val = 0x9c299f0 "rid=004,sid=000,csn="}, rid = 4, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} p sc1->ctxcsn[0] $4 = {bv_len = 40, bv_val = 0x9e98cf0 "20070925132254.897919Z#000000#000#000000"} (gdb) p sc1->ctxcsn[1] $5 = {bv_len = 0, bv_val = 0x0} (gdb) p sc1->sids[0] $6 = 0 (gdb) p sc1->sids[1] $7 = 159661424 (gdb) p sc2->ctxcsn[0] $8 = {bv_len = 0, bv_val = 0x0} (gdb) p sc2->sids[0] $9 = 0 Line numbers may be slightly off because of minimal customization which should not impact this functionality. Mi first question is: is "rid=004,sid=000,csn=" a legitimate cookie? If it is, the code must account for (not) calling compare_csns() when the ctxcsn member of either struct sync_cookie is NULL. In that case, I suggest the patch Index: servers/slapd/syncrepl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v retrieving revision 1.361 diff -u -r1.361 syncrepl.c --- servers/slapd/syncrepl.c 29 Sep 2007 14:11:28 -0000 1.361 +++ servers/slapd/syncrepl.c 1 Oct 2007 12:25:05 -0000 @@ -985,7 +985,13 @@ if ( !BER_BVISNULL( &syncCookie.octet_str ) ) { slap_parse_sync_cookie( &syncCookie, NULL ); - compare_csns( &syncCookie_req, &syncCookie, &m ); + m = 0; + if ( syncCookie.ctxcsn ) { + compare_csns( &syncCookie_req, &syncCookie, &m ); + } else { + /* otherwise it would be dereferenced few lines below */ + assert( !refreshDeletes ); + } } } if ( ber_peek_tag( ber, &len ) == So the second question, assuming the above cookie is legitimate, would be: is it legitimate that the above cookie will only occur with refreshDelete unset? 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 ---------------------------------------

2 16

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

03 Oct '07

piotr.tarnowski(a)us.edu.pl wrote: > Full_Name: Piotr Tarnowski (DrFugazi) > Version: 2.3.38 > OS: Solaris 10 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.158.96.61) > > > Hello, > > I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) > system. > I tried many times with many compilation options, but I still have an error with > 'gmake test': > >>>>>> Starting test001-slapadd ... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve all the entries... > Waiting 5 seconds for slapd to start... > 4378 Bus Error - core dumped > Waiting 5 seconds for slapd to start... Please read the FAQ http://www.openldap.org/faq/index.cgi?file=59 for information on how to obtain a trace. -- -- 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#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 03 Oct '07

03 Oct '07

--On October 2, 2007 10:20:45 PM +0000 quanah(a)zimbra.com wrote: > <http://bugzilla.zimbra.com/attachment.cgi?id=5896> Here's the full output, so one doesn't need to sign up to bugzilla to view it. Thread 26 (Thread 1082132832 (LWP 3925)): #0 0x0000003fca0c6c9c in epoll_wait () from /lib64/tls/libc.so.6 #1 0x000000000041c2fe in slapd_daemon_task () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 25 (Thread 1090525536 (LWP 3926)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 24 (Thread 1098918240 (LWP 3927)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x000000000042b951 in send_ldap_ber () #2 0x000000000042e961 in slap_send_search_entry () #3 0x00000000004cbdd1 in syncprov_qtask () #4 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #5 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #6 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #7 0x0000000000000000 in ?? () Thread 23 (Thread 1107310944 (LWP 3928)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x00000000420017e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000420017c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 22 (Thread 1115703648 (LWP 3929)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x0000000042803a00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000428039e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 21 (Thread 1124096352 (LWP 3930)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 20 (Thread 1132489056 (LWP 3931)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 19 (Thread 1140881760 (LWP 3932)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x0000000044006a00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000440069e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 18 (Thread 1149274464 (LWP 4038)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 17 (Thread 1157667168 (LWP 4039)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x00000000450087c0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047a98e in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x00000000450087a0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000424528 in fe_op_add () #12 0x0000000000424f5a in do_add () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 16 (Thread 1166059872 (LWP 4056)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 15 (Thread 1174452576 (LWP 4061)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004600a7c0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047a98e in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004600a7a0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000424528 in fe_op_add () #12 0x0000000000424f5a in do_add () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 14 (Thread 1182845280 (LWP 4316)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 1191237984 (LWP 4317)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 12 (Thread 1199630688 (LWP 10576)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004780da00 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004780d9e0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000434e3c in fe_op_delete () #12 0x0000000000434917 in do_delete () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 11 (Thread 1208023392 (LWP 10593)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 10 (Thread 1216416096 (LWP 10602)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 1224808800 (LWP 10603)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 8 (Thread 1233201504 (LWP 13176)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 7 (Thread 1241594208 (LWP 13177)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 1249986912 (LWP 13178)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 1258379616 (LWP 13179)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (Thread 1266772320 (LWP 13180)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004b8147e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004b8147c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 3 (Thread 1275165024 (LWP 13230)): #0 0x0000003fca90ae0b in __lll_mutex_lock_wait () #1 0x00000000004b4580 in accesslog_op_bind () #2 0x000000004c0157e0 in ?? () #3 0x0000003fca907be4 in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #4 0x000000000047aaeb in bdb_referrals () #5 0x000000000046fc24 in overlay_op_walk () #6 0x0000000000e11c40 in ?? () #7 0x0000000000e11e00 in ?? () #8 0x000000004c0157c0 in ?? () #9 0x0000000000e118c0 in ?? () #10 0x000000000046fd1f in over_op_func () #11 0x0000000000432c8e in fe_op_modify () #12 0x0000000000433fb4 in do_modify () #13 0x000000000041f11c in connection_operation () #14 0x000000000041f978 in connection_read_thread () #15 0x00000000004e2b2a in ldap_int_thread_pool_wrapper () #16 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #17 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #18 0x0000000000000000 in ?? () Thread 2 (Thread 1283557728 (LWP 13553)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004e2bab in ldap_int_thread_pool_wrapper () #2 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 182897791712 (LWP 3835)): #0 0x0000003fca906ffb in pthread_join () from /lib64/tls/libpthread.so.0 #1 0x000000000041cca1 in slapd_daemon () #2 0x000000000040d139 in main () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 03 Oct '07

03 Oct '07

--On October 2, 2007 10:20:45 PM +0000 quanah(a)zimbra.com wrote: >> This has nothing to do with BDB so db_stat isn't relevant here. It's >> about the accesslog overlay and any other overlays that may be >> manipulating the callback stack, so your slapd.conf is more relevant >> here. > Here's the slapd.conf (comments stripped): include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/openldap/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/openldap/schema/zimbra.schema" include "/opt/zimbra/lib/conf/zimbra-ext.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" TLSCertificateFile /opt/zimbra/conf/slapd.crt TLSCertificateKeyFile /opt/zimbra/conf/slapd.key TLSVerifyClient never access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,objectclass,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumb er,title,uid by dn.children="cn=admins,cn=zimbra" write by * read access to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryA ddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read database config rootpw {SSHA}XXXX database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read database bdb suffix cn=accesslog directory /opt/zimbra/openldap-data/accesslog/db rootdn cn=accesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read dbconfig set_cachesize 0 629145600 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /opt/zimbra/openldap-data/accesslog/logs dbconfig set_flags DB_LOG_AUTOREMOVE checkpoint 1024 5 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" rootpw {SSHA}XXXXXXX cachesize 300000 checkpoint 64 5 loglevel 256 threads 16 idlcachesize 300000 directory "/opt/zimbra/openldap-data" index objectClass eq index zimbraForeignPrincipal eq index zimbraId eq index zimbraVirtualHostname eq index zimbraMailCatchAllAddress eq,sub index zimbraMailDeliveryAddress eq,sub index zimbraMailForwardingAddress eq index zimbraMailAlias eq,sub index zimbraDomainName eq,sub index zimbraShareInfo sub index uid pres,eq index mail pres,eq,sub index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub index zimbraCalResSite eq,sub index zimbraCalResBuilding eq,sub index zimbraCalResFloor eq,sub index zimbraCalResRoom eq,sub index zimbraCalResCapacity eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 04+00:00 01+00:00 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 03 Oct '07

03 Oct '07

--On October 2, 2007 8:26:10 PM +0000 hyc(a)symas.com wrote: > Based on the (unreliable) pstack output it appears that all of the > threads are waiting for the same mutex. This of course shouldn't be > possible since one of those threads must already own it. We really need > to have gdb access here to inspect the state of the mutex and see which > thread is the owner, then figure out why it's trying to lock it again. > In OpenLDAP 2.3 this pretty much means that some operation locked the > mutex and somehow completed without unlocking it, i.e. completed without > going thru the accesslog response callback. > > This has nothing to do with BDB so db_stat isn't relevant here. It's > about the accesslog overlay and any other overlays that may be > manipulating the callback stack, so your slapd.conf is more relevant > here. I mainly wanted the db_stat information to make sure there were no held writelocks, which it is clear is not the case. I find I do have another pstack output from this same type of hang with another client at: <http://bugzilla.zimbra.com/attachment.cgi?id=5896> I'm working on getting the slapd.conf in question, but I believe the only overlays affecting the BDB backend are syncprov and accesslog. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5165) strtoul(3) might be used incorrectly
by ando＠sys-net.it 02 Oct '07

02 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 Occasionally, strtoul(3) is used in slapd(8) to parse integers that are expected to be unsigned. It seems that strtoul(3) is used under the assumption that it will fail if a negative number is encountered. This is not the case; in fact, by design, negative numbers are read as positive, and negated. If negative numbers are not allowed, strtol(3) should be used instead, and the value should be checked (or the string should be checked for '-' before calling strtoul(3). p.

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by hyc＠symas.com 02 Oct '07

02 Oct '07

quanah(a)zimbra.com wrote: > --On Tuesday, October 02, 2007 3:28 AM +0000 quanah(a)zimbra.com wrote: > >> --On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: >> >>> quanah(a)zimbra.com wrote: >>>> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >>>> >>>>> The following files will be uploaded to the ftp site, where # will be >>>>> the assigned ITS number. >>>> URL's specifically are: >>>> >>>> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >>>> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >>>> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> >>> The pstack output is a bit odd, is this a regular debug build? With frame >>> pointers, etc? Can you get a stack trace in gdb? >> It is a regular build, and they killed and restarted it before getting >> any gdb information. We've asked them to please get the gdb information >> in the future. Since it has happened twice now for thi particular group >> in about a month, I'm hopeful it'll happen again before too long. ;) > > And here is the last logged operation: > > Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD > dn="uid=XXXXXXX,ou=people,dc=YYYYYY,dc=com" > Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD > attr=zimbraLastLogonTimestamp Based on the (unreliable) pstack output it appears that all of the threads are waiting for the same mutex. This of course shouldn't be possible since one of those threads must already own it. We really need to have gdb access here to inspect the state of the mutex and see which thread is the owner, then figure out why it's trying to lock it again. In OpenLDAP 2.3 this pretty much means that some operation locked the mutex and somehow completed without unlocking it, i.e. completed without going thru the accesslog response callback. This has nothing to do with BDB so db_stat isn't relevant here. It's about the accesslog overlay and any other overlays that may be manipulating the callback stack, so your slapd.conf is more relevant 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: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 02 Oct '07

02 Oct '07

--On Tuesday, October 02, 2007 3:28 AM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: > >> quanah(a)zimbra.com wrote: >>> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >>> >>>> The following files will be uploaded to the ftp site, where # will be >>>> the assigned ITS number. >>> >>> URL's specifically are: >>> >>> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >>> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >>> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> >> >> The pstack output is a bit odd, is this a regular debug build? With frame >> pointers, etc? Can you get a stack trace in gdb? > > It is a regular build, and they killed and restarted it before getting > any gdb information. We've asked them to please get the gdb information > in the future. Since it has happened twice now for thi particular group > in about a month, I'm hopeful it'll happen again before too long. ;) And here is the last logged operation: Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD dn="uid=XXXXXXX,ou=people,dc=YYYYYY,dc=com" Oct 1 17:48:21 ldap01 slapd.bin[16121]: conn=62333 op=1 MOD attr=zimbraLastLogonTimestamp Then it just hung. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 02 Oct '07

02 Oct '07

This is a multi-part message in MIME format. --------------050900090302030708020604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Pierangelo Masarati a écrit : > Should be fixed now in HEAD/re24/re23. Please test. p. Hi, I've been testing (at last, sorry for the delay), and I've come across another memory problem. Backtrace is below, and valgrind output is attached. Please shout if you need any more information. Backtrace follows: 8<------------------------------------------------------------------- conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="ou=people,dc=linagora,dc=org" scope=2 deref=0 filter="(mail=li*)" <= bdb_substring_candidates: (mail) not indexed *** glibc detected *** double free or corruption (fasttop): 0x082e54c8 *** Program received signal SIGABRT, Aborted. [Switching to Thread 32771 (LWP 19881)] 0x40350b01 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40350b01 in kill () from /lib/libc.so.6 #1 0x402def65 in pthread_kill () from /lib/libpthread.so.0 #2 0x402defab in raise () from /lib/libpthread.so.0 #3 0x40350894 in raise () from /lib/libc.so.6 #4 0x40351ccc in abort () from /lib/libc.so.6 #5 0x40384b0f in __fsetlocking () from /lib/libc.so.6 #6 0x4038a080 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #7 0x4038b628 in free () from /lib/libc.so.6 #8 0x0813f736 in ber_bvarray_free_x (a=0x82e5470, ctx=0x82882b8) at memory.c:734 #9 0x080a15e3 in slap_set_dispose (cp=<value optimized out>, set=0x82e5470, flags=6) at sets.c:64 #10 0x080a1655 in slap_set_join (cp=0x62f5ab90, lset=0x82e5470, op_flags=16, rset=0x82e5470) at sets.c:335 #11 0x080a23f2 in slap_set_filter (gatherer=0x807f810 <acl_set_gather>, cp=0x62f5ab90, fbv=0x62f5ab98, user=0x82876a0, target=0x82e004c, results=0x0) at sets.c:445 #12 0x0807f5b9 in acl_match_set (subj=0x62f5b380, op=0x8287608, e=0x82e0040, default_set_attribute=0x0) at acl.c:2722 #13 0x08081b58 in access_allowed_mask (op=0x8287608, e=0x82e0040, desc=0x8217f00, val=0x82e40d8, access=ACL_READ, state=0x62f5b428, maskp=0x0) at acl.c:1884 #14 0x0806fa8e in slap_send_search_entry (op=0x8287608, rs=0x6301cce4) at result.c:894 #15 0x080c5eeb in bdb_search (op=0x8287608, rs=0x6301cce4) at search.c:879 #16 0x08062902 in fe_op_search (op=0x8287608, rs=0x6301cce4) at search.c:355 #17 0x080b6ff0 in overlay_op_walk (op=0x8287608, rs=0x6301cce4, which=op_search, oi=0x822fb08, on=0x81eb7d8) at backover.c:650 #18 0x080b73ee in over_op_func (op=0x8287608, rs=0x6301cce4, which=op_search) at backover.c:702 #19 0x0806320b in do_search (op=0x8287608, rs=0x6301cce4) at search.c:217 #20 0x080609db in connection_operation (ctx=0x6301cd58, arg_v=0x8287608) at connection.c:1133 #21 0x0811b664 in ldap_int_thread_pool_wrapper (xpool=0x81d1048) at tpool.c:478 #22 0x402dbc51 in pthread_start_thread () from /lib/libpthread.so.0 #23 0x402dbdb4 in pthread_start_thread_event () from /lib/libpthread.so.0 #24 0x403e238a in clone () from /lib/libc.so.6 8<------------------------------------------------------------------- Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------050900090302030708020604 Content-Type: text/plain; name="sets-bug-valgrind-output.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sets-bug-valgrind-output.txt" conn=0 fd=12 ACCEPT from IP=127.0.0.1:33726 (IP=0.0.0.0:391) conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="ou=people,dc=upmc,dc=fr" scope=2 deref=0 filter="(mail=li*)" <= bdb_substring_candidates: (mail) not indexed ==19986== ==19986== Thread 4: ==19986== Invalid read of size 4 ==19986== at 0x80A1459: slap_set_size (sets.c:34) ==19986== by 0x80A1671: slap_set_join (sets.c:249) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== Address 0x6074F7C is 4 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A1471: slap_set_size (sets.c:34) ==19986== by 0x80A1671: slap_set_join (sets.c:249) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== Address 0x6074F84 is 12 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A19A3: slap_set_join (sets.c:278) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F7C is 4 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A19DB: slap_set_join (sets.c:284) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F78 is 0 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A1B02: slap_set_join (sets.c:309) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F78 is 0 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A1B08: slap_set_join (sets.c:309) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F7C is 4 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 1 ==19986== at 0x401D570: memmove (mc_replace_strmem.c:503) ==19986== by 0x80A1B16: slap_set_join (sets.c:309) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== Address 0x6074FC7 is 7 bytes inside a block of size 16 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x813F735: ber_bvarray_free_x (memory.c:734) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== ==19986== Invalid read of size 1 ==19986== at 0x401D579: memmove (mc_replace_strmem.c:503) ==19986== by 0x80A1B16: slap_set_join (sets.c:309) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== Address 0x6074FC5 is 5 bytes inside a block of size 16 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x813F735: ber_bvarray_free_x (memory.c:734) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A1B27: slap_set_join (sets.c:310) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F78 is 0 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x80A1A95: slap_set_join (sets.c:278) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== by 0x80609DA: connection_operation (connection.c:1133) ==19986== by 0x811B663: ldap_int_thread_pool_wrapper (tpool.c:478) ==19986== Address 0x6074F84 is 12 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x813F6EF: ber_bvarray_free_x (memory.c:730) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== Address 0x6074F7C is 4 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x813F704: ber_bvarray_free_x (memory.c:730) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== Address 0x6074F84 is 12 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid read of size 4 ==19986== at 0x813F728: ber_bvarray_free_x (memory.c:734) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== Address 0x6074F7C is 4 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== ==19986== Invalid free() / delete / delete[] ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x813F735: ber_bvarray_free_x (memory.c:734) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== Address 0x6074FC0 is 0 bytes inside a block of size 16 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x813F735: ber_bvarray_free_x (memory.c:734) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== ==19986== Invalid free() / delete / delete[] ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A23F1: slap_set_filter (sets.c:445) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) ==19986== Address 0x6074F78 is 0 bytes inside a block of size 24 free'd ==19986== at 0x401BFA5: free (vg_replace_malloc.c:233) ==19986== by 0x80A15E2: slap_set_dispose (sets.c:64) ==19986== by 0x80A1638: slap_set_join (sets.c:334) ==19986== by 0x80A1F1F: slap_set_filter (sets.c:471) ==19986== by 0x807F5B8: acl_match_set (acl.c:2722) ==19986== by 0x8081B57: access_allowed_mask (acl.c:1884) ==19986== by 0x806FA8D: slap_send_search_entry (result.c:894) ==19986== by 0x80C5EEA: bdb_search (search.c:879) ==19986== by 0x8062901: fe_op_search (search.c:355) ==19986== by 0x80B6FEF: overlay_op_walk (backover.c:650) ==19986== by 0x80B73ED: over_op_func (backover.c:702) ==19986== by 0x806320A: do_search (search.c:217) --------------050900090302030708020604--

1 0

Re: (ITS#5164) slapi plugins prevent slapd starting.
by m.d.t.evans＠qmul.ac.uk 02 Oct '07

02 Oct '07

this hack makes it start... but i doubt that it is the right fix. bash-3.1$ diff -u slapi_overlay.c.0 slapi_overlay.c --- slapi_overlay.c.0 2007-09-01 00:14:07.000000000 +0100 +++ slapi_overlay.c 2007-10-02 15:32:09.000000000 +0100 @@ -900,8 +900,11 @@ slapi.on_bi.bi_op_abandon = slapi_op_func; slapi.on_bi.bi_op_cancel = slapi_op_func; - slapi.on_bi.bi_db_open = slapi_over_db_open; - slapi.on_bi.bi_db_close = slapi_over_db_close; +// slapi.on_bi.bi_db_open = slapi_over_db_open; +// slapi.on_bi.bi_db_close = slapi_over_db_close; + + slapi.on_bi.bi_db_open = NULL; + slapi.on_bi.bi_db_close = NULL; slapi.on_bi.bi_extended = slapi_over_extended; slapi.on_bi.bi_access_allowed = slapi_over_access_allowed; -- -- Dr MDT Evans, Computing Services, Queen Mary, University of London

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

>> I would have expected the problem to show up more frequently, if I >> just need to use a filter that will result in attributes being cached. > > well, the issue you seem to see is quite clear; probably it doesn't show > up that frequently because by chance there happens to be a NULL somewhere > along the path before a SIGSEGV is triggered. Running slapd under > valgrind or similar memory debuggers would probably track it much quicker. > And there might be more; only, this is for sure a bug. OK, yes, I see what you're saying. I'll patch and report back. Toby

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by ando＠sys-net.it 02 Oct '07

02 Oct '07

> I would have expected the problem to show up more frequently, if I > just need to use a filter that will result in attributes being cached. well, the issue you seem to see is quite clear; probably it doesn't show up that frequently because by chance there happens to be a NULL somewhere along the path before a SIGSEGV is triggered. Running slapd under valgrind or similar memory debuggers would probably track it much quicker. And there might be more; only, this is for sure a bug. 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#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

Hi there, Firstly, thanks for the really quick reply. > I think this issue has been already fixed, incidentally, in HEAD/re24, but > went unnoticed in re23. You should replace the call to ch_malloc() that's > around line 1140 in servers/slapd/overlays/pcache.c with a call to > ch_calloc(); something like > > *new_attrs = (AttributeName*)ch_calloc( count + 1, > sizeof(AttributeName)); Yep, it's there - line 1138. I'll patch this and report back. > (sorry, I can't access the network right now but by webmail). In > fact, right now, the array of AttributeName "new_attrs" is accessed > by an_find() while not yet NULL terminated. Please check and report > (to create the problem, you need to use filters that contain the > attributes that will be cached). I would have expected the problem to show up more frequently, if I just need to use a filter that will result in attributes being cached. Cheers Toby

1 0

(ITS#5164) slapi plugins prevent slapd starting.
by m.d.t.evans＠qmul.ac.uk 02 Oct '07

02 Oct '07

Full_Name: Martin Evans Version: 2.4.5beta OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (138.37.8.140) This is mentioned in #4611 but marked as fixed there. If you compile and load in the plugin from 4611 slapd does not start and you get the following errors from -d-1: ... 2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) slapd startup: initiated. backend_startup: bi_db_open(frontend) failed! (1) slapd shutdown: initiated ====> bdb_cache_release_all backend_startup: bi_db_close(frontend) failed! (1) slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. This is the plugin from 4611: #include "slapi-plugin.h" #include <stdio.h> int auth(Slapi_PBlock *pb) { slapi_send_ldap_result( pb, 0, NULL, NULL, 0, NULL ); return (0); } int auth_plugin_init(Slapi_PBlock *pb) { if (slapi_pblock_set( pb, SLAPI_PLUGIN_PRE_BIND_FN, (void*) auth) != 0) { slapi_log_error(SLAPI_LOG_PLUGIN, "auth", "Error registering function.\n" ); return (-1); } slapi_log_error( SLAPI_LOG_PLUGIN, "auth_plugin_init", "Plug-ins successfully registered.\n" ); return (0); }

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by ando＠sys-net.it 02 Oct '07

02 Oct '07

> While running slapd as a proxy-caching server, it sometimes falls over > with a > signal 11 segfault. I haven't been able to reproduce this and it can > occur when > the system is quiet and nothing much running.... I think this issue has been already fixed, incidentally, in HEAD/re24, but went unnoticed in re23. You should replace the call to ch_malloc() that's around line 1140 in servers/slapd/overlays/pcache.c with a call to ch_calloc(); something like *new_attrs = (AttributeName*)ch_calloc( count + 1, sizeof(AttributeName)); (sorry, I can't access the network right now but by webmail). In fact, right now, the array of AttributeName "new_attrs" is accessed by an_find() while not yet NULL terminated. Please check and report (to create the problem, you need to use filters that contain the attributes that will be cached). 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#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

Full_Name: Toby Blake Version: 2.3.38 OS: Fedora Core 5/6 URL: Submission from: (NULL) (129.215.218.33) While running slapd as a proxy-caching server, it sometimes falls over with a signal 11 segfault. I haven't been able to reproduce this and it can occur when the system is quiet and nothing much running.... Core was generated by `/usr/sbin/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 Here's the db portion of slapd.conf: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://testdir.inf.ed.ac.uk/" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 2 500 300 proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 1 cn userPassword memberUid uniqueMember gidNumber nisNe tgroupTriple memberNisNetgroup objectClass proxytemplate (uid=) 0 1800 1800 proxytemplate (&(objectClass=)(uid=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 1 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 1 1800 1800 directory /var/openldap-data dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd.conf.indices And, here's the full backtrace from gdb... #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 No symbol table info available. #1 0x0809c83d in an_find (a=0xb0c412d0, s=0xad1f8994) at ad.c:842 No locals. #2 0x08117321 in pcache_op_search (op=0xb0c271b8, rs=0xad6f91c4) at pcache.c:1150 cb = <value optimized out> on = (slap_overinst *) 0x8a4f9d0 cm = (cache_manager *) 0x8a4fac0 qm = (query_manager *) 0x8a6aed8 i = <value optimized out> filter_attrs = (AttributeName *) 0xad1f896c query = {filter = 0xb0c3d178, attrs = 0xb0c411b8, save_attrs = 0xad1f88cc, base = {bv_len = 24, bv_val = 0xad1f81e4 "dc=inf,dc=ed,dc=ac,dc=uk"}, scope = 2} attr_set = 0 template_id = 3 answerable = <value optimized out> cacheable = 1 fattr_cnt = 3 fattr_got_oc = 1 tempstr = {bv_len = 47, bv_val = 0xad1f88fc "(&(objectClass=)(|(memberUid=)(uniqueMember=)))"} #3 0x080bb404 in overlay_op_walk (op=0xb0c271b8, rs=0xad6f91c4, which=op_search, oi=0x8a4f8e0, on=0x8a4f9d0) at backover.c:639 rc = -1329434184 #4 0x080bb89d in over_op_func (op=0xb0c271b8, rs=0xad6f91c4, which=op_search) at backover.c:701 oi = (slap_overinfo *) 0x8a4f8e0 on = (slap_overinst *) 0x8a4f9d0 be = (BackendDB *) 0x8a4f4c8 db = {bd_info = 0x8a4f9d0, be_ctrls = "\000", '\001' <repeats 14 times>, '\0' <repeats 17 times>, "\001", be_flags = 257, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8a6af10, be_nsuffix = 0x8a6ade0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 64, bv_val = 0x8a4f838 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootndn = {bv_len = 64, bv_val = 0x8a4f898 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 24576, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a6a6c0, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8aa4820, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x8a4f598, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81cd360, be_private = 0x8a4f5d0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80bb180 <over_back_response>, sc_cleanup = 0, sc_private = 0x8a4f8e0} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #5 0x0806316f in fe_op_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:355 entry = (Entry *) 0xad6f8118 bd = (BackendDB *) 0x81d1240 #6 0x08063b21 in do_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:217 base = {bv_len = 24, bv_val = 0xb0c40440 "dc=inf,dc=ed,dc=ac,dc=uk"} siz = 1 i = 1 #7 0x080611f9 in connection_operation (ctx=0xad6f9238, arg_v=0xb0c271b8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0xb6885288 memctx = (void *) 0x8b0c630 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x08131fd3 in ldap_int_thread_pool_wrapper (xpool=0x8a324f8) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0xb0c16600 ltc_key = {{ltk_key = 0x80ac320, ltk_data = 0x8b0c630, ltk_free = 0x80ac210 <slap_sl_mem_destroy>}, {ltk_key = 0x8aa5430, ltk_data = 0x9b, ltk_free = 0x80e9550 <bdb_locker_id_free>}, { ltk_key = 0x80c9170, ltk_data = 0xac9f7008, ltk_free = 0x80c9230 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2909772688 i = 583 hash = <value optimized out> #9 0x0093945b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0x0089123e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) Please let me know if any more deugging information would be useful. Cheers Toby Blake University of Edinburgh

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs