- openldap-bugs - openldap.org

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

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

02 Oct '07

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... ------------ In tests/testrun/slapd.1.log I found: daemon: select: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x001cbef0 ptr=0x001cbef0 end=0x001cbefc len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: select: listen=8 active_threads=0 tvp=NULL do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbef3 end=0x001cbefc len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbefa end=0x001cbefc len=2 0000: 00 00 .. >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 conn=0 op=0 BIND dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=0 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 63 31 04 06...c1. ldap_read: want=48, got=48 0000: 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 .dc=example,dc=c 0010: 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 om.............. 0020: 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ...objectclass0. ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x001acdd8 ptr=0x001acdd8 end=0x001ace0e len=54 0000: 02 01 02 63 31 04 11 64 63 3d 65 78 61 6d 70 6c ...c1..dc=exampl 0010: 65 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 e,dc=com........ 0020: 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 .........objectc 0030: 6c 61 73 73 30 00 lass0. ber_get_next do_search ldap_read: want=8 error=Resource temporarily unavailable ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x001acdd8 ptr=0x001acddb end=0x001ace0e len=51 0000: 63 31 04 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 c1..dc=example,d 0010: 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 c=com........... 0020: 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 ......objectclas 0030: 73 30 00 s0. daemon: select: listen=8 active_threads=0 tvp=NULL >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x001acdd8 ptr=0x001acdff end=0x001ace0e len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x001acdd8 ptr=0x001ace0c end=0x001ace0e len=2 ----------- Output from truss: (...) 26487/3: write(2, " b d b _ d n 2 e n t r y".., 34) = 34 26487/3: write(2, " = > b d b _ d n 2 i d".., 34) = 34 26487/3: write(2, " < = b d b _ d n 2 i d".., 32) = 32 26487/3: Incurred fault #5, FLTACCESS %pc = 0x7E72B4D0 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26487/3: Received signal #10, SIGBUS [default] 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26392: waitid(P_PID, 26517, 0xFFBFF5C0, WEXITED|WTRAPPED|WNOWAIT) (sleeping...) (...) ------------- Is this a software error, or compiler/system issue ? I use Sun Studio 12 on sparc. 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 Regards -- Piotr (DrFugazi) Tarnowski

1 0

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

01 Oct '07

--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. ;) --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 hyc＠symas.com 01 Oct '07

01 Oct '07

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

01 Oct '07

--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> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

01 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) Several customers have found delta-syncrepl will lock up after a time. Today it occurred again, and this time some logging data was able to be gathered. The last operation logged was a MOD op. This matches past lockups, which were also either MOD or ADD operations. The following files will be uploaded to the ftp site, where # will be the assigned ITS number. #-dbstat.delta.out.2007-10-01 which is the db_stat information for the accesslog DB #-db_stat.out.2007-10-01 which is the db_stat information for the main DB #-pstak.out.2007-10-01 which is the pstack information for the slapd process Unfortunately no GDB info was retrieved this time, and reportedly gcore hung. The most interesting part is I see no WRITE locks held in either DB, and all the client threads are hung in a mutex.

1 0

Re: (ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by hyc＠symas.com 01 Oct '07

01 Oct '07

jclarke(a)linagora.com wrote: > I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and > behaviour is quite different, though the end result is the same. Due to multiple limitations, this is not expected to work in 2.3 at all. > On HEAD, things are quite different: > request done: ld 0x82c2228 msgid 2 > do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT > nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn > dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn > uid=root,dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn > uid=replicator,dc=ossa,dc=linagora,dc=org > adresse de be_modify : 80c8840 > null_callback : error code 0x32 > syncrepl_updateCookie: rid=7 be_modify failed (50) This is Insufficient Access. You have not configured the glue databases with identical rootDN's, which is clearly documented as a requirement for glued databases. -- -- 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#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by jclarke＠linagora.com 01 Oct '07

01 Oct '07

Full_Name: Jonathan Clarke Version: 2.3.38 and HEAD (but with slightly different results) OS: Linux URL: ftp://ftp.openldap.org/incoming/unwanted-deletes-syncrepl-glue.tar.gz Submission from: (NULL) (213.41.243.192) Hi folks, I've come across an issue with a server using the glue overlay with one of it's subordinate databases syncrepl'd. There are two problems: 1) updating the root database's contextCSN 2) when replicating this whole server with syncrepl (to a 3rd server), certain updates cause many entries to be deleted from the consumer. The following "schema" should describe this setup more clearly (names TOP, MIDDLE and BOTTOM are for easy reference): TOP: |----------------------------| | One bdb backend: | | dc=ossa,dc=linagora,dc=org | |----------------------------| | MIDDLE: | |-------------------------------| | Two bdb backends + glue: | | 1) dc=ossa,dc=linagora,dc=org | | subordinate | | syncrepl from above server | | 2) dc=linagora,dc=org | | 'master' for this branch | | | | syncprov overlay | |-------------------------------| | BOTTOM: | |-------------------------------| | One bdb backend: | | dc=linagora,dc=org | | syncrepl from above server | |-------------------------------| All config files, and some sample data sets, are in the archive at the URL above. I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and behaviour is quite different, though the end result is the same. On 2.3.38: 1) Set up all three servers, make sure they're sync'ed. 2) Modify some attribute on the TOP server (I add a description to the root DN, dc=ossa,dc=linagora,dc=org) 3) Watch this modification propagate to the middle server. the contextCSN in dc=linagora,dc=org is not updated, but the one in dc=ossa,dc=linagora,dc=org is (equals to the entryCSN of the entry I modified). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822ec20 msgid 1 do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 007 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 007 be_search (0) syncrepl_entry: rid 007 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 007 be_modify (0) request done: ld 0x822ec20 msgid 2 do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT 8>--------------------------------------------------------------- 4) Watch the BOTTOM server (see schema above) do it's syncrepl and delete some entries below the glued database (glued on MIDDLE server, not on this one). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822a320 msgid 1 request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT request done: ld 0x822a320 msgid 1 do_syncrep2: rid 888 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT syncrepl_del_nonpresent: rid 888 be_delete uid=replicator,dc=ossa,dc=linagora,dc=org (0) syncrepl_del_nonpresent: rid 888 be_delete uid=root,dc=ossa,dc=linagora,dc=org (0) 8>--------------------------------------------------------------- On HEAD, things are quite different: 1) Start the TOP server. 2) Start the MIDDLE server. Errors happen immediatly, on first sync attempt. The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- slapd starting request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f syncrepl_entry: rid=7 be_search (32) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) request done: ld 0x82c2228 msgid 2 do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn uid=root,dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn uid=replicator,dc=ossa,dc=linagora,dc=org adresse de be_modify : 80c8840 null_callback : error code 0x32 syncrepl_updateCookie: rid=7 be_modify failed (50) request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f dn_callback : entries have identical CSN dc=ossa,dc=linagora,dc=org ours 20071001162546.703481Z#000000#000#000000, new 20071001162546.703481Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f dn_callback : entries have identical CSN uid=root,dc=ossa,dc=linagora,dc=org ours 20071001162546.975377Z#000000#000#000000, new 20071001162546.975377Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=root,dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f dn_callback : entries have identical CSN uid=replicator,dc=ossa,dc=linagora,dc=org ours 20071001162546.976133Z#000000#000#000000, new 20071001162546.976133Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=replicator,dc=ossa,dc=linagora,dc=org) 8>--------------------------------------------------------------- Obviously, the desired result is that entries are not deleted from the BOTTOM server when replication happens. I'm a bit at a loss as to the logic behind these updates, and how to go about correcting. I tried applying a patch backported from HEAD to 2.3.38 that makes syncrepl update the contextCSN in the real root (not the bdb database root). It works in that the contextCSN is updated correctly, but replication to BOTTOM still has unwanted deletes. The patch is in the archive attached (update-root-contextCSN.diff) and corresponds to revisions 1.308 and 1.309 in syncrepl.c CVS log. I am completely available to provide any more information necessary: logs, testing, gdb output, etc. Any help or pointers most welcome! Thanks in advance, Jon

1 0

Re: (ITS#4467) snprintf is consistenly used wrongly
by ando＠sys-net.it 29 Sep '07

29 Sep '07

h.b.furuseth(a)usit.uio.no wrote: > OpenLDAP is full of code like > ptr += snprintf( ptr, ... ); > and > bv.bv_len = snprintf( ... ); > <use bv>; Let me add that there seem to be occasional improper uses of sprintf() too (usually in marginal code, fortunately). 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#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> I just got tripped trying to import an LDIF with a cert with 16 byte >> SerialNumber. I've patched this to just use the same hexadecimal format that >> OpenSSL uses when the number is larger than ber_int_t. We really don't want >> the format to change just because someone has a BigNum library available; it >> needs to stay consistent. > > But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. > And in case somebody feeds in a very large decimal integer, we still need a > multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. OK. Does it make any sense to just move to a hex-only syntax, perfixed by "0x", with no sign as you mentioned earlier, or should we preserve compatibility with the original form, where the minus sign is allowed while a number not starting with "0x" should be treated as decimal? The latter would be probably better, but we'd need to convert decimal to hex, and this could fail if decimals are too large. 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#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 29 Sep '07

29 Sep '07

Howard Chu wrote: > I just got tripped trying to import an LDIF with a cert with 16 byte > SerialNumber. I've patched this to just use the same hexadecimal format that > OpenSSL uses when the number is larger than ber_int_t. We really don't want > the format to change just because someone has a BigNum library available; it > needs to stay consistent. But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. And in case somebody feeds in a very large decimal integer, we still need a multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. -- -- 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#5146) slapo-ppolicy
by ando＠sys-net.it 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Of course now that userPassword and authPassword already exist, all the good > attribute names are already gone. ;) "password"? 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#5159) make slap_passwd_parse() non-destructive
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc In RE23 the slap_passwd_parse() function parses the exop data destructively, so it cannot be successfully parsed again by any other function that needs to. In HEAD there is a new LBER option to specify non-destructive parsing of strings, and slap_passwd_parse() has been changed to use this option.

1 0

(ITS#5158) contrib should use separate config OID arc
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Currently we track config OID allocations in slapd/bconfig.c for both core modules and contrib modules. Since we really aren't maintaining the contrib modules, they should use a separate OID arc and the OIDs should be tracked elsewhere. This has been changed in HEAD, and contrib/ConfigOIDs now exists for tracking OIDs allocated to contrib modules.

1 0

(ITS#5157) dynlist shouldn't populate values unless requested
by hyc＠OpenLDAP.org 28 Sep '07

28 Sep '07

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Since populating the member list in a dynamic group may be a very expensive operation, the dynlist overlay should not perform this work if the member attribute wasn't requested in the search parameters. Already fixed in HEAD.

1 0

(ITS#5156) missing slapd.d man page
by gerard.ranke＠kmt.hku.nl 27 Sep '07

27 Sep '07

Full_Name: Gerard Ranke Version: 2.3.35, 2.3.38 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) Section 5.2 from the OpenLDAP Administrator's Guide mentions the slapd.d(5) man page. However, this seems to be missing from the distribution. Would it be possible to add it? Thanks for your time and effort. Best regards, Gerard Ranke

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 26 Sep '07

26 Sep '07

On Sonntag, 23. September 2007, ando(a)sys-net.it wrote: > Ralf Haferkamp wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > I added tests for sizelimit that were consistent with my changes; > however, I'm now short of time to work on this, so feel free to back out > those test changes if you believe the code is working correctly, while > we design test improvements that are consistent with all fixes. I have rearranged the pcache test case a bit. It succeeds now on my test machine. -- Ralf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs