openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7472) syncrepl conflicting write resolution trouble
by hyc＠symas.com 11 Dec '12

11 Dec '12

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4.33+ITS#7427 > OS: > URL: > Submission from: (NULL) (98.155.30.248) > > > We are seeing a condition under heavy conflicting-write load-- i.e. changes to > the same DN from multiple nodes in a syncrepl MMR cluster at the same time-- > where the content of the entry is desynchronized between servers. > > There is a non-reproduced case with incomplete logs where servers traded entry > versions, even with one CSN significantly (by one second) later than the other. > I'll supply more info if that reappears. > > Additionally, we have a -d logged case of a conflicting write resulting in > different changes applied on different servers while the same CSN gets applied > to both, which seems truly bizarre. > > The expected case is that one server "wins" the conflict and its state is sent > to all of the others, eventually. Analyzing the logs shows this is an unresolvable conflict in plain syncrepl/MMR. Please note that the Admin Guide already documents the fact that consistency is not guaranteed in this mode. (Section 18.2.2.3.) The solution, as documented, is to use mirrormode. > All of these results are using back-hdb. More details soon, hopefully. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7472) syncrepl conflicting write resolution trouble
by ebackes＠symas.com 11 Dec '12

11 Dec '12

Full_Name: Emily Backes Version: 2.4.33+ITS#7427 OS: URL: Submission from: (NULL) (98.155.30.248) We are seeing a condition under heavy conflicting-write load-- i.e. changes to the same DN from multiple nodes in a syncrepl MMR cluster at the same time-- where the content of the entry is desynchronized between servers. There is a non-reproduced case with incomplete logs where servers traded entry versions, even with one CSN significantly (by one second) later than the other. I'll supply more info if that reappears. Additionally, we have a -d logged case of a conflicting write resulting in different changes applied on different servers while the same CSN gets applied to both, which seems truly bizarre. The expected case is that one server "wins" the conflict and its state is sent to all of the others, eventually. While most likely unrelated, we're also still seeing massive desynchronization from conflicting writes involving modifies and deletes, where the deletes are sent under heavy load such that the commits occur out of order and result in a cookie-less syncrepl event-- these (Despite #7427) can still resurrect entries later. All of these results are using back-hdb. More details soon, hopefully.

1 0

(ITS#7471) MDB resize on the fly is broken in RE24
by quanah＠OpenLDAP.org 11 Dec '12

11 Dec '12

Full_Name: Quanah Gibson-Mount Version: RE24 12/11/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) In the 2.4.33 release of OpenLDAP, it was possibly to resize an MDB database by modifying olcDbMaxsize while slapd was running. This functionality no longer works in current RE24. This is highly desirable behavior, as one may wish to reduce the maximum DB size after determining how large the actual MDB is. With current RE24, changing olcDbMaxsize to a smaller value leaves the data.mdb file the same size as it was before. 2.4.33 behavior: 80GB initial maxsize: zimbra@zre-ldap002:~$ ls -l data/ldap/mdb/db total 692 -rw------- 1 zimbra zimbra 85899345920 Dec 11 10:46 data.mdb After modifying cn=config with a 10MB maxsize: zimbra@zre-ldap002:~$ ls -l data/ldap/mdb/db total 692 -rw------- 1 zimbra zimbra 10485760 Dec 11 10:51 data.mdb

1 0

Re: (ITS#7470) RE24 MDB corrupts over time
by quanah＠zimbra.com 11 Dec '12

11 Dec '12

--On Tuesday, December 11, 2012 6:31 PM +0000 openldap-its(a)OpenLDAP.org wrote: Never mind, old build before latest patches. --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

1 0

(ITS#7470) RE24 MDB corrupts over time
by quanah＠OpenLDAP.org 11 Dec '12

11 Dec '12

Full_Name: Quanah Gibson-Mount Version: RE24 12/11/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) Over time, the MDB database corrupts with write traffic. Dec 10 23:54:39 zqa-384 slapd[28213]: slap_queue_csn: queing 0x7f81a6d8d1a0 20121211075439.646157Z#000000#000#000000 Dec 10 23:54:39 zqa-384 slapd[28213]: slap_graduate_commit_csn: removing 0x64c6e70 20121211075439.646157Z#000000#000#000000 Dec 10 23:54:39 zqa-384 slapd[28213]: slap_queue_csn: queing 0x7f81a5d8b1a0 20121211075439.660500Z#000000#000#000000 Dec 10 23:54:40 zqa-384 postfix/smtpd[17272]: connect from zqa-384.eng.vmware.com[10.137.245.129] Dec 10 23:54:40 zqa-384 postfix/proxymap[17273]: error: dict_ldap_connect: Unable to set STARTTLS: -1: Can't contact LDAP server Dec 10 23:54:40 zqa-384 postfix/trivial-rewrite[17274]: warning: proxy:ldap:/opt/zimbra/conf/ldap-vad.cf: table lookup problem Dec 10 23:54:40 zqa-384 postfix/trivial-rewrite[17274]: warning: virtual_alias_domains lookup failure Dec 10 23:54:40 zqa-384 postfix/proxymap[17273]: error: dict_ldap_connect: Unable to set STARTTLS: -1: Can't contact LDAP server Dec 10 23:54:40 zqa-384 postfix/trivial-rewrite[17274]: warning: proxy:ldap:/opt/zimbra/conf/ldap-vad.cf: table lookup problem Dec 10 23:54:40 zqa-384 postfix/trivial-rewrite[17274]: warning: virtual_alias_domains lookup failure Dec 10 23:54:40 zqa-384 postfix/smtpd[17272]: NOQUEUE: reject: RCPT from zqa-384.eng.vmware.com[10.137.245.129]: 451 4.3.0 <admin(a)zqa-384.eng.vmware.com>: Temporary lookup failure; from=<admin(a)zqa-384.eng.vmware.com> to=<test1355212480752.21277(a)zqa-384.eng.vmware.com> proto=ESMTP helo=<zqa-384.eng.vmware.com> zimbra@zqa-384:~$ mdb_stat -eaf data/ldap/mdb/db mdb_env_open failed, error -30793 MDB_INVALID: File is not an MDB file

1 0

Re: (ITS#7469) MDB double free when slapcatting a subtree
by quanah＠zimbra.com 10 Dec '12

10 Dec '12

--On Tuesday, December 11, 2012 1:07 AM +0000 openldap-its(a)OpenLDAP.org wrote: zimbra@zre-ldap001:~$ valgrind /opt/zimbra/openldap/sbin/slapcat -F /opt/zimbra/data/ldap/config -b "" -s dc=com -l /tmp/blah.ldif ==3554== Memcheck, a memory error detector ==3554== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3554== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==3554== Command: /opt/zimbra/openldap/sbin/slapcat -F /opt/zimbra/data/ldap/config -b -s dc=com -l /tmp/blah.ldif ==3554== ==3554== Invalid read of size 8 ==3554== at 0x66A63C4: __strspn_sse42 (smmintrin.h:510) ==3554== by 0x4E681F8: ldap_pvt_strtok (string.c:92) ==3554== by 0x499C4E: str2anlist (ad.c:936) ==3554== by 0x47388B: parse_acl (aclparse.c:473) ==3554== by 0x41A454: config_generic (bconfig.c:1825) ==3554== by 0x42E1DB: config_set_vals (config.c:345) ==3554== by 0x42E73A: config_add_vals (config.c:418) ==3554== by 0x42F45B: config_parse_add (config.c:689) ==3554== by 0x425A1B: config_add_internal (bconfig.c:5182) ==3554== by 0x421E40: config_ldif_resp (bconfig.c:3990) ==3554== by 0x453E2B: slap_response_play (result.c:507) ==3554== by 0x455A44: slap_send_search_entry (result.c:1011) ==3554== Address 0x6afc0f8 is 8 bytes inside a block of size 13 alloc'd ==3554== at 0x4C275D8: malloc (vg_replace_malloc.c:236) ==3554== by 0x509AFD5: ber_memalloc_x (memory.c:228) ==3554== by 0x509B910: ber_strdup_x (memory.c:638) ==3554== by 0x463B0E: ch_strdup (ch_malloc.c:121) ==3554== by 0x499BA2: str2anlist (ad.c:924) ==3554== by 0x47388B: parse_acl (aclparse.c:473) ==3554== by 0x41A454: config_generic (bconfig.c:1825) ==3554== by 0x42E1DB: config_set_vals (config.c:345) ==3554== by 0x42E73A: config_add_vals (config.c:418) ==3554== by 0x42F45B: config_parse_add (config.c:689) ==3554== by 0x425A1B: config_add_internal (bconfig.c:5182) ==3554== by 0x421E40: config_ldif_resp (bconfig.c:3990) ==3554== ==3554== Invalid read of size 8 ==3554== at 0x66A63AD: __strspn_sse42 (emmintrin.h:679) ==3554== by 0x4E681F8: ldap_pvt_strtok (string.c:92) ==3554== by 0x499E1F: str2anlist (ad.c:938) ==3554== by 0x47388B: parse_acl (aclparse.c:473) ==3554== by 0x41A454: config_generic (bconfig.c:1825) ==3554== by 0x42E1DB: config_set_vals (config.c:345) ==3554== by 0x42E73A: config_add_vals (config.c:418) ==3554== by 0x42F45B: config_parse_add (config.c:689) ==3554== by 0x425A1B: config_add_internal (bconfig.c:5182) ==3554== by 0x421E40: config_ldif_resp (bconfig.c:3990) ==3554== by 0x453E2B: slap_response_play (result.c:507) ==3554== by 0x455A44: slap_send_search_entry (result.c:1011) ==3554== Address 0xa57bbc8 is 40 bytes inside a block of size 46 alloc'd ==3554== at 0x4C275D8: malloc (vg_replace_malloc.c:236) ==3554== by 0x509AFD5: ber_memalloc_x (memory.c:228) ==3554== by 0x509B910: ber_strdup_x (memory.c:638) ==3554== by 0x463B0E: ch_strdup (ch_malloc.c:121) ==3554== by 0x499BA2: str2anlist (ad.c:924) ==3554== by 0x47388B: parse_acl (aclparse.c:473) ==3554== by 0x41A454: config_generic (bconfig.c:1825) ==3554== by 0x42E1DB: config_set_vals (config.c:345) ==3554== by 0x42E73A: config_add_vals (config.c:418) ==3554== by 0x42F45B: config_parse_add (config.c:689) ==3554== by 0x425A1B: config_add_internal (bconfig.c:5182) ==3554== by 0x421E40: config_ldif_resp (bconfig.c:3990) ==3554== 50c689a0 mdb_db_open: database "" cannot be opened, err 22. Restore from backup! 50c689a0 backend_startup_one (type=mdb, suffix=""): bi_db_open failed! (22) slap_startup failed ==3554== ==3554== HEAP SUMMARY: ==3554== in use at exit: 3,904,527 bytes in 46,449 blocks ==3554== total heap usage: 89,842 allocs, 43,393 frees, 31,218,836 bytes allocated ==3554== ==3554== LEAK SUMMARY: ==3554== definitely lost: 0 bytes in 0 blocks ==3554== indirectly lost: 0 bytes in 0 blocks ==3554== possibly lost: 0 bytes in 0 blocks ==3554== still reachable: 3,904,527 bytes in 46,449 blocks ==3554== suppressed: 0 bytes in 0 blocks ==3554== Rerun with --leak-check=full to see details of leaked memory ==3554== ==3554== For counts of detected and suppressed errors, rerun with: -v ==3554== ERROR SUMMARY: 8 errors from 2 contexts (suppressed: 59 from 5) --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

1 0

Re: (ITS#7469) MDB double free when slapcatting a subtree
by quanah＠zimbra.com 10 Dec '12

10 Dec '12

--On Tuesday, December 11, 2012 1:07 AM +0000 openldap-its(a)OpenLDAP.org wrote: #0 0x00007ffff633fa75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 pid = <value optimized out> selftid = <value optimized out> #1 0x00007ffff63435c0 in *__GI_abort () at abort.c:92 act = {__sigaction_handler = {sa_handler = 0x7fffffffd850, sa_sigaction = 0x7fffffffd850}, sa_mask = {__val = {140737488345360, 140737488350338, 43, 140737325127087, 3, 140737488345370, 6, 140737325127091, 2, 140737488345358, 2, 140737325118168, 1, 140737325127087, 3, 140737488345364}}, sa_flags = 12, sa_restorer = 0x7ffff64555b3} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff637974b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffe290, reg_save_area = 0x7fffffffe1a0}} ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fffffffe290, reg_save_area = 0x7fffffffe1a0}} fd = 8 on_2 = <value optimized out> list = <value optimized out> nlist = 1024 cp = <value optimized out> written = false #3 0x00007ffff6383806 in malloc_printerr (action=3, str=0x7ffff64572f0 "double free or corruption (fasttop)", ptr=<value optimized out>) at malloc.c:6266 buf = "0000000000d1d310" cp = 0x7ffff644d300 "0123456789abcdefghijklmnopqrstuvwxyz" #4 0x00007ffff638a0d3 in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3738 ar_ptr = 0x7ffff668ae40 p = 0x7ffff644d300 #5 0x00007ffff7972e91 in ber_memfree_x (p=0xd1d310, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #6 0x0000000000463bef in ch_free (ptr=0xd1d310) at ch_malloc.c:139 ctx = 0x0 #7 0x00007ffff380287a in mdb_entry_return (op=0x7fffffffe6b0, e=0xd1d330) at id2entry.c:243 No locals. #8 0x00007ffff38028ec in mdb_entry_release (op=0x7fffffffe6b0, e=0xd1d330, rw=0) at id2entry.c:265 mdb = 0x8c0600 moi = 0x0 rc = 0 #9 0x00000000004d421e in overlay_entry_release_ov (op=0x7fffffffe6b0, e=0xd1d330, rw=0, on=0x0) at backover.c:434 oi = 0x8b9850 be = 0x8b3490 db = {bd_info = 0x0, bd_self = 0x0, be_ctrls = '\000' <repeats 32 times>, be_flags = 140737347270259, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 4294960368, sss_transport = 32767, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 8121104, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x7fffffffe4f0, be_nsuffix = 0x7fffffffe4d0, be_schemadn = {bv_len = 140737347270493, bv_val = 0x7fffffffe4f0 "\017"}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 8121104, bv_val = 0x0}, be_rootndn = {bv_len = 76, bv_val = 0x7fffffffe520 "\300\345\377\377\377\177"}, be_rootpw = {bv_len = 140737349714310, bv_val = 0x7972616e69623b <Address 0x7972616e69623b out of bounds>}, be_max_deref_depth = 8121104, be_def_limit = {lms_t_soft = 0, lms_t_hard = 15, lms_s_soft = 0, lms_s_hard = 8121104, lms_s_unchecked = 0, lms_s_pr = -6720, lms_s_pr_hide = 32767, lms_s_pr_total = 4280592}, be_limits = 0x7fffffffea30, be_acl = 0x4c, be_dfltaccess = -6720, be_extra_anlist = 0x7ffff7bc86ec, be_update_ndn = {bv_len = 76, bv_val = 0xf <Address 0xf out of bounds>}, be_update_refs = 0x7febf29d2fec, be_pending_csn_list = 0x7beb10, be_pcl_mutex = {__data = {__lock = 0, __count = 1, __owner = 7733832, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x4, __next = 0x20}}, __size = "\000\000\000\000\001\000\000\000H\002v", '\000' <repeats 13 times>, "\004\000\000\000\000\000\000\000 \000\000\000\000\000\000", __align = 4294967296}, be_syncinfo = 0x10, be_pb = 0xd3c897, be_cf_ocs = 0x0, be_private = 0x7febf29d2ffb, be_next = {stqe_next = 0x7febf29d2ffb}} bi = 0x8b9850 rc = 32768 #10 0x00000000004d430d in over_entry_release_rw (op=0x7fffffffe6b0, e=0xd1d330, rw=0) at backover.c:463 oi = 0x8b9850 on = 0x8bee10 __PRETTY_FUNCTION__ = "over_entry_release_rw" #11 0x00000000004507ca in be_entry_release_rw (op=0x7fffffffe6b0, e=0xd1d330, rw=0) at backend.c:886 No locals. #12 0x00000000004d9815 in slapcat (argc=9, argv=0x7fffffffea38) at slapcat.c:152 data = 0xd3c730 "dn:: AAAAAAAA\nobjectClass: organization\nobjectClass: dcObject\no: com domain\ndc: com\nstructuralObjectClass: organization\nentryUUID: acf761e8-d5d2-1031-88ffda6f3a93b\ncreatorsName: uid=zimbra,cn=admi"... len = 376 e = 0xd1d330 id = 33 rc = 0 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x8b3490, 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}} progname = 0x51a858 "slapcat" requestBSF = 1 doBSF = 0 __PRETTY_FUNCTION__ = "slapcat" #13 0x00000000004158f0 in main (argc=9, argv=0x7fffffffea38) at main.c:410 i = 1 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {-154148864, 32767} g_argc = 9 g_argv = 0x7fffffffea38 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffeca6 "slapcat" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9aa8 "" l = 140737323823448 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7469) MDB double free when slapcatting a subtree
by quanah＠OpenLDAP.org 10 Dec '12

10 Dec '12

Full_Name: Quanah Gibson-Mount Version: RE24 12/10/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) zimbra@zre-ldap001:~$ /opt/zimbra/openldap/sbin/slapcat -F /opt/zimbra/data/ldap/config -b "" -s "cn=zimbra" -l /tmp/z.ldif *** glibc detected *** /opt/zimbra/openldap/sbin/slapcat: double free or corruption (fasttop): 0x00000000025a8310 *** ======= Backtrace: ========= /lib/libc.so.6(+0x77806)[0x7fbe15574806] /lib/libc.so.6(cfree+0x73)[0x7fbe1557b0d3] /opt/zimbra/openldap-2.4.33.3z/lib/liblber-2.4.so.2(ber_memfree_x+0x39)[0x7fbe16b63e91] /opt/zimbra/openldap/sbin/slapcat(ch_free+0x49)[0x463bef] /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_mdb-2.4.so.2(mdb_entry_return+0xb9)[0x7fbe129f387a] /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_mdb-2.4.so.2(mdb_entry_release+0x41)[0x7fbe129f38ec] /opt/zimbra/openldap/sbin/slapcat(overlay_entry_release_ov+0x201)[0x4d421e] /opt/zimbra/openldap/sbin/slapcat[0x4d430d] /opt/zimbra/openldap/sbin/slapcat(be_entry_release_rw+0x50)[0x4507ca] /opt/zimbra/openldap/sbin/slapcat(slapcat+0x536)[0x4d9815] /opt/zimbra/openldap/sbin/slapcat(main+0x161)[0x4158f0] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fbe1551bc4d] /opt/zimbra/openldap/sbin/slapcat[0x415139] ======= Memory map: ======== 00400000-00555000 r-xp 00000000 fb:00 7352232 /opt/zimbra/openldap-2.4.33.3z/sbin/slapd 00755000-00756000 r--p 00155000 fb:00 7352232 /opt/zimbra/openldap-2.4.33.3z/sbin/slapd 00756000-0075f000 rw-p 00156000 fb:00 7352232 /opt/zimbra/openldap-2.4.33.3z/sbin/slapd 0075f000-007b2000 rw-p 00000000 00:00 0 0203d000-025e8000 rw-p 00000000 00:00 0 [heap] 7faa0c000000-7faa0c021000 rw-p 00000000 00:00 0 7faa0c021000-7faa10000000 ---p 00000000 00:00 0 7faa11959000-7faa1196f000 r-xp 00000000 fb:00 262196 /lib/libgcc_s.so.1 7faa1196f000-7faa11b6e000 ---p 00016000 fb:00 262196 /lib/libgcc_s.so.1 7faa11b6e000-7faa11b6f000 r--p 00015000 fb:00 262196 /lib/libgcc_s.so.1 7faa11b6f000-7faa11b70000 rw-p 00016000 fb:00 262196 /lib/libgcc_s.so.1 7faa11b75000-7fbe11b75000 r--s 00000000 fb:00 7351893 /opt/zimbra/data/ldap/mdb/db/data.mdb 7fbe11b75000-7fbe11d76000 rw-p 00000000 00:00 0 7fbe11d76000-7fbe11d78000 r-xp 00000000 fb:00 7352301 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/noopsrch.so.0.0.0 7fbe11d78000-7fbe11f77000 ---p 00002000 fb:00 7352301 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/noopsrch.so.0.0.0 7fbe11f77000-7fbe11f78000 r--p 00001000 fb:00 7352301 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/noopsrch.so.0.0.0 7fbe11f78000-7fbe11f79000 rw-p 00002000 fb:00 7352301 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/noopsrch.so.0.0.0 7fbe11f79000-7fbe11f80000 r-xp 00000000 fb:00 7352321 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/unique-2.4.so.2.8.5 7fbe11f80000-7fbe12180000 ---p 00007000 fb:00 7352321 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/unique-2.4.so.2.8.5 7fbe12180000-7fbe12181000 r--p 00007000 fb:00 7352321 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/unique-2.4.so.2.8.5 7fbe12181000-7fbe12182000 rw-p 00008000 fb:00 7352321 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/unique-2.4.so.2.8.5 7fbe12182000-7fbe1218a000 r-xp 00000000 fb:00 7352272 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/dynlist-2.4.so.2.8.5 7fbe1218a000-7fbe12389000 ---p 00008000 fb:00 7352272 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/dynlist-2.4.so.2.8.5 7fbe12389000-7fbe1238a000 r--p 00007000 fb:00 7352272 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/dynlist-2.4.so.2.8.5 7fbe1238a000-7fbe1238b000 rw-p 00008000 fb:00 7352272 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/dynlist-2.4.so.2.8.5 7fbe1238b000-7fbe12398000 r-xp 00000000 fb:00 7352348 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/accesslog-2.4.so.2.8.5 7fbe12398000-7fbe12597000 ---p 0000d000 fb:00 7352348 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/accesslog-2.4.so.2.8.5 7fbe12597000-7fbe12598000 r--p 0000c000 fb:00 7352348 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/accesslog-2.4.so.2.8.5 7fbe12598000-7fbe12599000 rw-p 0000d000 fb:00 7352348 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/accesslog-2.4.so.2.8.5 7fbe12599000-7fbe125a9000 r-xp 00000000 fb:00 7352294 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/syncprov-2.4.so.2.8.5 7fbe125a9000-7fbe127a8000 ---p 00010000 fb:00 7352294 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/syncprov-2.4.so.2.8.5 7fbe127a8000-7fbe127a9000 r--p 0000f000 fb:00 7352294 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/syncprov-2.4.so.2.8.5 7fbe127a9000-7fbe127aa000 rw-p 00010000 fb:00 7352294 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/syncprov-2.4.so.2.8.5 7fbe127aa000-7fbe127c8000 r-xp 00000000 fb:00 7352252 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_monitor-2.4.so.2.8.5 7fbe127c8000-7fbe129c7000 ---p 0001e000 fb:00 7352252 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_monitor-2.4.so.2.8.5 7fbe129c7000-7fbe129c8000 r--p 0001d000 fb:00 7352252 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_monitor-2.4.so.2.8.5 7fbe129c8000-7fbe129ca000 rw-p 0001e000 fb:00 7352252 /opt/zimbra/openldap-2.4.33.3z/sbin/openldap/back_monitor-2.4.so.2.8.5Aborted

1 0

Re: (ITS#7456) slapo-smbk5pwd: Makefile with -L
by quanah＠zimbra.com 10 Dec '12

10 Dec '12

--On Tuesday, December 04, 2012 6:47 PM +0000 michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms080001080509060504090401 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Quanah Gibson-Mount wrote: >> I'm not talking specifically about slapo-smbk5pwd testing. ;) I'm talk= > ing >> about the commits for ITS7308 and ITS7309, which touched a significant = > number >> of files. Generally we need someone to go through contrib and verify t= > hings >> build ok. > > Yeah, no problem. > > My build script currently contains the lines below for overlays I'm always= > s > using. Please apply the patches to RE24 and I will test as many overlays = > as > possible. Now in RE24, please test. --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

1 0

Re: (ITS#7466) syncreplication causes massive explosion in database size
by hyc＠symas.com 09 Dec '12

09 Dec '12

andrew.findlay(a)skills-1st.co.uk wrote: > On Fri, Dec 07, 2012 at 08:29:59PM +0000, quanah(a)zimbra.com wrote: > >> Subject: Re: (ITS#7466) syncreplication causes massive explosion in >> database size > >> Closing. Issue was actually triggered by the core dump in ITS#7465, which >> left a read txn lock on the primary database, causing the freelist to not >> be able to compact. Rebuilding the database cleared the lock and things >> went back to normal. > > Would it be possible for slapd to recover from such a case > automatically on startup? If so, then I think it should. > If not, then I think it is worth mentioning this in the > documentation or an FAQ. The library is designed to clean up automatically. The outstanding bugs (#7465) prevent that from working at the moment in RE24. This is not going to be an issue in the released code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs