Full_Name: David Hawes Version: 2.4.24 OS: Ubuntu 10.04 URL: Submission from: (NULL) (128.173.39.26) When using slapadd or slapindex with the -q option, the message "Closing DB..." is printed and then the application hangs indefinitely. Removing the -q option allows the application to complete without issue. This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. slapd.conf: ===== include /usr/local/openldap-2.4.24/etc/openldap/schema/core.schema pidfile /usr/local/openldap-2.4.24/var/run/slapd.pid argsfile /usr/local/openldap-2.4.24/var/run/slapd.args database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" directory /usr/local/openldap-2.4.24/var/openldap-data dbconfig set_lg_dir /usr/local/openldap-2.4.24/var/openldap-data/bdb-logs dbconfig set_lg_max 104857600 dbconfig set_lg_bsize 26214400 dbconfig set_cachesize 4 0 1 dbconfig set_flags DB_LOG_AUTOREMOVE ===== ldif: dn: dc=test,dc=com objectClass: dcObject objectClass: organization o: testorg dc: test
--On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.24 > OS: Ubuntu 10.04 > URL: > Submission from: (NULL) (128.173.39.26) > > > When using slapadd or slapindex with the -q option, the message "Closing > DB..." is printed and then the application hangs indefinitely. Removing > the -q option allows the application to complete without issue. > > This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. I would ask you provide a full backtrace of the slapadd process after it has hung. Otherwise, this report isn't of much use. Also, if you are using the Ubuntu patches for OpenLDAP with your OpenLDAP build, you are including a known database-corrupting patch. Since you don't say how you built OpenLDAP, it is impossible for us to know if you did this or not. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: > --On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote: > >> Full_Name: David Hawes >> Version: 2.4.24 >> OS: Ubuntu 10.04 >> URL: >> Submission from: (NULL) (128.173.39.26) >> >> >> When using slapadd or slapindex with the -q option, the message "Closing >> DB..." is printed and then the application hangs indefinitely. Removing >> the -q option allows the application to complete without issue. >> >> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. > > I would ask you provide a full backtrace of the slapadd process after it > has hung. Otherwise, this report isn't of much use. > > Also, if you are using the Ubuntu patches for OpenLDAP with your > OpenLDAP build, you are including a known database-corrupting patch. > Since you don't say how you built OpenLDAP, it is impossible for us to > know if you did this or not. Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu packages or code is used. Backtraces (I may need to recompile without optimization): (gdb) thread apply all bt Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff677970d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 #4 0x0000000000466059 in slap_destroy () at init.c:273 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 (gdb) thread apply all bt full Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 env = 0x886270 wrote = 0 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 pool = 0x844f00 task = 0x89dc30 work_list = <value optimized out> ctx = {ltu_id = 140732807526144, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdbc08, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0xa8428197, ltk_free = 0x7ffff7de7457}, {ltk_key = 0x0, ltk_data = 0x2a10a06, ltk_free = 0x17}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7fda0f0, ltk_free = 0x7ffff7fdb4c0}, { ltk_key = 0x0, ltk_data = 0x7ffff66a3660, ltk_free = 0x7ffff7631f50}, {ltk_key = 0x0, ltk_data = 0x1000003bb, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd868, ltk_free = 0x7ffee9002e10}, { ltk_key = 0x0, ltk_data = 0x7ffee9002e38, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7de7722, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd510, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9002dc0, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7633cef}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0x7ffff7fdb4c0}, {ltk_key = 0x0, ltk_data = 0xffffffff, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x218050, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9003700, ltk_free = 0x7ffff7631000}, { ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7638ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x800000 <hbuf+48096>}, { ltk_key = 0x0, ltk_data = 0x7ffff7df2325, ltk_free = 0x7ffee9003700}}} kctx = <value optimized out> keyslot = 285 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff677970d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 pool = 0x844f00 pptr = 0x844f00 task = <value optimized out> #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x844f00 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #4 0x0000000000466059 in slap_destroy () at init.c:273 rc = 0 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 rc = 0 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 buf = 0x89de00 "\240Љ" text = 0x0 textbuf = '\000' <repeats 255 times> maxcsn = {{bv_len = 0, bv_val = 0x0} <repeats 3928 times>, { bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7fffffffddc0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a0fb40 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0xffffffffa2000000 <Address 0xffffffffa2000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdb000 ""}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, { bv_len = 140737488343856, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737488346672, bv_val = 0x7 <Address 0x7 out of bounds>}, { bv_len = 140737353992808, bv_val = 0x7ffff7dea64d "H\213\205p\377\377\377\213\215\370\376\377\377L\213\205"}, {bv_len = 140737354127792, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6c2be00 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb000 ""}, {bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 140737488343856, bv_val = 0xffffffffa4000000 <Address 0xffffffffa4000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7de3dae "H\203\370\377\017\205a\373\377\377L\215\r\360>\001"}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdca68 ""}, {bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 140737488344096, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6c2bf70 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdca68 ""}, { bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, { bv_len = 140737488344096, bv_val = 0xffffffffa5e00000 <Address 0xffffffffa5e00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x218a88 <Address 0x218a88 out of bounds>}, { bv_len = 86016, bv_val = 0x3 <Address 0x3 out of bounds>}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc508 ""}, { bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, { bv_len = 140737488344336, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6fa2738 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353990144, bv_val = 0x7ffff7fdb4c0 ""}, { bv_len = 0, bv_val = 0x7ffff7fdc508 ""}, {bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 140737488344336, bv_val = 0xffffffffa7c00000 <Address 0xffffffffa7c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x1 <Address 0x1 out of bounds>}, {bv_len = 0, bv_val = 0x7ffff7de3bf5 "\366E\020\bu\016H\203\273\300"}, { bv_len = 8030813564919442479, bv_val = 0x7fffff00362e <Address 0x7fffff00362e out of bounds>}, { bv_len = 140737354129704, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7ffff720cee0 ""}, { bv_len = 140737353988792, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353992808, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0xffffffffa9c00000 <Address 0xffffffffa9c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x4d6fb0ac <Address 0x4d6fb0ac out of bounds>}, { bv_len = 331622242, bv_val = 0x4d3a077c <Address 0x4d3a077c out of bounds>}, { bv_len = 0, bv_val = 0x4d488e48 <Address 0x4d488e48 out of bounds>}, { bv_len = 530906511, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7415f40 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x7ffff7ffd9b0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 4294967296, bv_val = 0x7ffff762fc90 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0xffffffffabe00000 <Address 0xffffffffabe00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x0}, {bv_len = 832, bv_val = 0x10102464c457f <Address 0x10102464c457f out of bounds>}, {bv_len = 0, bv_val = 0x1003e0003 <Address 0x1003e0003 out of bounds>}, { bv_len = 126304, bv_val = 0x40 <Address 0x40 out of bounds>}, { bv_len = 1567688, bv_val = 0x38004000000000 <Address 0x38004000000000 out of bounds>}, {bv_len = 19703553316618250, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdd510 ""}, { bv_len = 1, bv_val = 0x7ffff7634dce "ld-linux-x86-64.so.2"}, { bv_len = 140737488345152, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff762fde0 ""}} sid = <value optimized out> bvtext = {bv_len = 256, bv_val = 0x7fffffffdd30 ""} attr = 0x0 ctxcsn_e = 0x0 ctxcsn_id = <value optimized out> id = <value optimized out> opbuf = {ob_op = {o_hdr = 0x7fffffffd9e0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x86ff40, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = { bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = { rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = { rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = { oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>}, ob_controls = { 0x0 <repeats 32 times>}} match = 32767 checkvals = 0 lineno = 7 nextline = 7 ldifrc = <value optimized out> lmax = 4115 rc = 0 enable_meter = 1 meter = {display = 0x589b80, display_data = 0x0, estimator = 0x589ba0, estimator_data = 0x0, start_time = 1299184379.2546861, last_update = 1299184379.2546861, goal_value = 88, last_position = 0} stat_buf = {st_dev = 21, st_ino = 6956686, st_nlink = 1, st_mode = 33188, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 88, st_blksize = 4096, st_blocks = 24, st_atim = {tv_sec = 1299166918, tv_nsec = 420393930}, st_mtim = { tv_sec = 1299166819, tv_nsec = 830383674}, st_ctim = { tv_sec = 1299166819, tv_nsec = 870399305}, __unused = {0, 0, 0}} __PRETTY_FUNCTION__ = "slapadd" #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 i = <value optimized out> no_detach = 32767 rc = 1 urls = <value optimized out> username = 0x374208 <Address 0x374208 out of bounds> groupname = 0x1 <Address 0x1 out of bounds> sandbox = 0x7fffffffdf1f "" syslogUser = 160 configfile = 0x4131e9 "__libc_start_main" configdir = 0xbf <Address 0xbf out of bounds> serverName = 0x7fffffffe380 "slapadd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 slapd_pid_file_unlink = <value optimized out> slapd_args_file_unlink = <value optimized out> firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"
--On Thursday, March 03, 2011 8:50 PM +0000 dhawes@vt.edu wrote: > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): My personal experience with gcc & openldap is that building an optimized version of OpenLDAP is an extremely bad idea, as gcc makes very bad choices. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
changed notes changed state Open to Test moved from Incoming to Software Bugs
dhawes@vt.edu wrote: > On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote: >> >>> Full_Name: David Hawes >>> Version: 2.4.24 >>> OS: Ubuntu 10.04 >>> URL: >>> Submission from: (NULL) (128.173.39.26) >>> >>> >>> When using slapadd or slapindex with the -q option, the message "Closing >>> DB..." is printed and then the application hangs indefinitely. Removing >>> the -q option allows the application to complete without issue. >>> >>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >> >> I would ask you provide a full backtrace of the slapadd process after it >> has hung. Otherwise, this report isn't of much use. >> >> Also, if you are using the Ubuntu patches for OpenLDAP with your >> OpenLDAP build, you are including a known database-corrupting patch. >> Since you don't say how you built OpenLDAP, it is impossible for us to >> know if you did this or not. > > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): > > (gdb) thread apply all bt > > Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1253 > #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( > xpool=<value optimized out>) at tpool.c:685 > #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 > #4 0x00007ffff677970d in clone () from /lib/libc.so.6 > #5 0x0000000000000000 in ?? () This indicates that the trickle task is still waiting for a signal on its condition variable. Which is a bit odd since bdb_tool_entry_close() already signals it before slap_tool_destroy() is called. It might be illuminating to run slapadd under gdb with a breakpoint on bdb_tool_entry_close(), and singlestep through the first few lines of that function where it issues the signal, and see if the trickle task actually reacts or not. > Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): > #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy > (tpool=0x7ffffffed658, > run_pending=<value optimized out>) at tpool.c:582 > #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 > #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 > #4 0x0000000000466059 in slap_destroy () at init.c:273 > #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 > #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) > at slapadd.c:606 > #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, March 04, 2011 9:08 PM +0000 hyc@symas.com wrote: > dhawes@vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message >>>> "Closing DB..." is printed and then the application hangs >>>> indefinitely. Removing the -q option allows the application to >>>> complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1253 >> # 2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> # 3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> # 4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> # 5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() > already signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of > that function where it issues the signal, and see if the trickle task > actually reacts or not. > >> Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): >> # 0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> # 1 0x0000000000506223 in ldap_pvt_thread_pool_destroy >> (tpool=0x7ffffffed658, >> run_pending=<value optimized out>) at tpool.c:582 >> # 2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at >> # tpool.c:181 3 0x00000000005050a9 in ldap_pvt_thread_destroy () at >> # threads.c:70 4 0x0000000000466059 in slap_destroy () at init.c:273 >> # 5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 >> # 6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) >> at slapadd.c:606 >> # 7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at >> # main.c:407 We are seeing numerous reports of this occurring with Zimbra after using OpenLDAP 2.4.23 + the multi-core fix (ITS#6660) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 03/04/2011 04:08 PM, hyc@symas.com wrote: > dhawes@vt.edu wrote: >> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: >>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote: >>> >>>> Full_Name: David Hawes >>>> Version: 2.4.24 >>>> OS: Ubuntu 10.04 >>>> URL: >>>> Submission from: (NULL) (128.173.39.26) >>>> >>>> >>>> When using slapadd or slapindex with the -q option, the message "Closing >>>> DB..." is printed and then the application hangs indefinitely. Removing >>>> the -q option allows the application to complete without issue. >>>> >>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. >>> >>> I would ask you provide a full backtrace of the slapadd process after it >>> has hung. Otherwise, this report isn't of much use. >>> >>> Also, if you are using the Ubuntu patches for OpenLDAP with your >>> OpenLDAP build, you are including a known database-corrupting patch. >>> Since you don't say how you built OpenLDAP, it is impossible for us to >>> know if you did this or not. >> >> Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu >> packages or code is used. >> >> Backtraces (I may need to recompile without optimization): >> >> (gdb) thread apply all bt >> >> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): >> #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib/libpthread.so.0 >> #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, >> ptr=<value optimized out>) at tools.c:1253 >> #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( >> xpool=<value optimized out>) at tpool.c:685 >> #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 >> #4 0x00007ffff677970d in clone () from /lib/libc.so.6 >> #5 0x0000000000000000 in ?? () > > This indicates that the trickle task is still waiting for a signal on its > condition variable. Which is a bit odd since bdb_tool_entry_close() already > signals it before slap_tool_destroy() is called. > > It might be illuminating to run slapadd under gdb with a breakpoint on > bdb_tool_entry_close(), and singlestep through the first few lines of that > function where it issues the signal, and see if the trickle task actually > reacts or not. Setting a breakpoint on bdb_tool_entry_close() and then either continuing or stepping through the function allows slapadd to exit cleanly.
dhawes@vt.edu wrote: > On 03/04/2011 04:08 PM, hyc@symas.com wrote: >> This indicates that the trickle task is still waiting for a signal on its >> condition variable. Which is a bit odd since bdb_tool_entry_close() already >> signals it before slap_tool_destroy() is called. >> >> It might be illuminating to run slapadd under gdb with a breakpoint on >> bdb_tool_entry_close(), and singlestep through the first few lines of that >> function where it issues the signal, and see if the trickle task actually >> reacts or not. > > Setting a breakpoint on bdb_tool_entry_close() and then either > continuing or stepping through the function allows slapadd to exit cleanly. A fix for this is now in HEAD, please test. back-bdb/tools.c 1.140 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 03/04/2011 05:56 PM, hyc@symas.com wrote: > dhawes@vt.edu wrote: >> On 03/04/2011 04:08 PM, hyc@symas.com wrote: >>> This indicates that the trickle task is still waiting for a signal on its >>> condition variable. Which is a bit odd since bdb_tool_entry_close() already >>> signals it before slap_tool_destroy() is called. >>> >>> It might be illuminating to run slapadd under gdb with a breakpoint on >>> bdb_tool_entry_close(), and singlestep through the first few lines of that >>> function where it issues the signal, and see if the trickle task actually >>> reacts or not. >> >> Setting a breakpoint on bdb_tool_entry_close() and then either >> continuing or stepping through the function allows slapadd to exit cleanly. > > A fix for this is now in HEAD, please test. > back-bdb/tools.c 1.140 > Tested, and working. Thanks for the fix.
--On March 4, 2011 11:14:46 PM +0000 dhawes@vt.edu wrote: > Tested, and working. Thanks for the fix. We're still seeing this happen sporadically with slapindex -q <attribute> i.e., reindexing a single attribute instead of the entire DB Thread 2 (Thread 0x96591ba0 (LWP 10652)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0xb776bf80, mutex=0xb776bf50) at thr_posix.c:277 No locals. #3 0xb77376f4 in bdb_tool_trickle_task (ctx=0x965912bc, ptr=0x82eb728) at tools.c:1242 env = 0x82eb728 wrote = -1208699249 #4 0xb7f4a33c in ldap_int_thread_pool_wrapper (xpool=0x81bda78) at tpool.c:685 pool = 0x81bda78 task = 0x82ee038 work_list = 0x81bdaf8 ctx = {ltu_id = 2522422176, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f9b049, ltk_free = 0xb7dcc732}, { ltk_key = 0x0, ltk_data = 0xb7fa7ff4, ltk_free = 0xb7bffd80}, {ltk_key = 0x0, ltk_data = 0x96591388, ltk_free = 0xb7f963d0 <do_lookup_x+640>}, {ltk_key = 0x0, ltk_data = 0xb7dcc75a, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0x69cb120}, {ltk_key = 0x0, ltk_data = 0xd696910, ltk_free = 0xe}, {ltk_key = 0x0, ltk_data = 0xb7a874a0, ltk_free = 0xb7a8ffe0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x2, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0xb7fa7ff4}, {ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0x96591428}, { ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0xb7fa8830}, {ltk_key = 0x0, ltk_data = 0xb7bf7dd8, ltk_free = 0x1}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7f272a0, ltk_free = 0xb7dcb69d}, {ltk_key = 0x0, ltk_data = 0x1000000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0xb7a8f000, ltk_free = 0xb7bf7508}, {ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0xb7f272a0}, {ltk_key = 0x0, ltk_data = 0xb7f9a24d, ltk_free = 0xb7f27448}, {ltk_key = 0x0, ltk_data = 0x1, ltk_free = 0x1}}} kctx = 0x0 i = 32 keyslot = 522 hash = 5777930 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0xb7dce35b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0xb7b43c0e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread 0xb7a826b0 (LWP 10610)): #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0x81bda94, mutex=0x81bda7c) at thr_posix.c:277 No locals. #3 0xb7f49fe7 in ldap_pvt_thread_pool_destroy (tpool=0xbf995780, run_pending=0) at tpool.c:582 pool = 0x81bda78 pptr = 0x81bda78 task = 0x0 #4 0xb7f49332 in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x81bda78 #5 0xb7f48aa0 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #6 0x080af918 in slap_destroy () at init.c:273 rc = 0 #7 0x080ff5f2 in slap_tool_destroy () at slapcommon.c:865 rc = 0 #8 0x080ffb9b in slapindex (argc=1, argv=0xbf9959bc) at slapindex.c:107 id = 4294967295 rc = 0 progname = 0x813ae0a "slapindex" ad = 0x8239440 adv = 0xbf9959bc __PRETTY_FUNCTION__ = "slapindex" #9 0x08057783 in main (argc=7, argv=0xbf9959a4) at main.c:403 i = 3 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = 0xbf9959a4 configfile = 0x0 configdir = 0x0 serverName = 0xbf997206 "slapindex" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x811c33f "" l = 134548137 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote: > > > --On March 4, 2011 11:14:46 PM +0000 dhawes@vt.edu wrote: >> Tested, and working. Thanks for the fix. > > We're still seeing this happen sporadically with slapindex -q<attribute> > > i.e., reindexing a single attribute instead of the entire DB Can't reproduce it here, need a test case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On March 9, 2011 9:42:18 AM -0800 Howard Chu <hyc@symas.com> wrote: > Quanah Gibson-Mount wrote: >> >> >> --On March 4, 2011 11:14:46 PM +0000 dhawes@vt.edu wrote: >>> Tested, and working. Thanks for the fix. >> >> We're still seeing this happen sporadically with slapindex -q<attribute> >> >> i.e., reindexing a single attribute instead of the entire DB > > Can't reproduce it here, need a test case. It's hard to come up with one. We've only had this one instance on one machine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
changed notes changed state Test to Active
Quanah Gibson-Mount wrote: > > > --On March 9, 2011 9:42:18 AM -0800 Howard Chu<hyc@symas.com> wrote: > >> Quanah Gibson-Mount wrote: >>> >>> >>> --On March 4, 2011 11:14:46 PM +0000 dhawes@vt.edu wrote: >>>> Tested, and working. Thanks for the fix. >>> >>> We're still seeing this happen sporadically with slapindex -q<attribute> >>> >>> i.e., reindexing a single attribute instead of the entire DB >> >> Can't reproduce it here, need a test case. > > It's hard to come up with one. We've only had this one instance on one > machine. I reproduced your hang by adding a sleep(1) in front of the trickle task. This patch fixes it. I can't commit at the moment because cvs-master.openldap.org is not answering. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Active to Test
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24