openldap-bugs October 2007

openldap-bugs@openldap.org

38 participants
215 discussions

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

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

06 Oct '07

hyc(a)symas.com wrote: > I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence > with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no > such error occurs there. > > Also this report (which it seems the original is no longer accessible) implies > the same problem with mcheck > > http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… > Eh... Looking at glibc's mcheck code http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc shows that it has no mutex protection at all. It is completely invalid here, this ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 06 Oct '07

06 Oct '07

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

1 0

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

06 Oct '07

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

1 0

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

06 Oct '07

I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no such error occurs there. Also this report (which it seems the original is no longer accessible) implies the same problem with mcheck http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/g… -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 06 Oct '07

06 Oct '07

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

1 0

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

06 Oct '07

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

1 0

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

06 Oct '07

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

1 0

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

06 Oct '07

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

1 0

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

06 Oct '07

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

1 0

← Newer
1
...
14
15
16
17
18
19
20
21
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2007