openldap-bugs June 2016

openldap-bugs@openldap.org

29 participants
73 discussions

Re: (ITS#8437) openldap-2.4.44 slapd.conf: back-sql database parameters, only first character
by piero.astolfi＠gmx.com 10 Jun '16

10 Jun '16

Switching from iodbc to unixodbc solved my issue.

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by hyc＠symas.com 09 Jun '16

09 Jun '16

quanah(a)zimbra.com wrote: > --On Thursday, June 09, 2016 1:19 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > >> quanah(a)openldap.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.44 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.52.177) >>> >>> >>> In MMR node, when there is > 2 nodes, operations can get sent out >>> endlessly. >>> >>> For example, we see this modification occur at 20160603194926.427963Z >> >> You seem to have a large clock sync problem. Summary: after fixing the clock skew, the problem was still present. Analyzing debug logs with sync+stats+packets, we see that the offending mods were propagated by syncprov without a CSN in the sync cookie. Since the cookie contained no CSN, the existing check for "CSN too old, ignoring" was not taking place, so the mods were not being filtered out as they should be. syncprov sends mods out without a CSN in the cookie when the mod's CSN is older than the newest contextCSN. In this particular case, between the time that the provider processed the original mod, and the time it was queued up to be sent to the relevant consumers, this server's own consumers had received newer updates from other providers. So, the mod was older than the current contextCSN and was sent without a cookie CSN. (The usual case for syncprov's behavior is when queued mods get sent out of order; since transmission order is not guaranteed to be the same as write/commit order this is a normal occurrence.) It's possible that regular syncrepl+mmr needs a corresponding fix. I haven't looked at that yet. -- -- 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#8440) syncrepl improvements for delta-sync mmr
by quanah＠openldap.org 09 Jun '16

09 Jun '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Syncprov currently skips contextCSN updates to the main DB, but not the accesslog DB in delta-syncrepl configurations. Consumers correctly ignore this traffic with "CSN too old" messages, but the syncprov code to ignore the updates in the main db should be extended to cover the accesslog DB to cut out this unnecessary traffic.

1 0

Re: (ITS#8433) slapd deadlocks on shutdown in 3+ MMR configuration with active writes
by quanah＠openldap.org 09 Jun '16

09 Jun '16

--On Wednesday, June 08, 2016 11:39 PM +0000 hyc(a)symas.com wrote: > Thread 3 is inside OpenSSL, it thinks there are 433 bytes to read on this > socket and it's waiting for them to arrive. There's not much we can do in > slapd about this. Going back through my notes on when we hit this before with customers, the following are the steps necessary to trigger these deadlocks: a) Must have 2+ replication agreements per node. This will not occur in 2 MMR node environments b) starttls is used in all the replication agreements c) There needs to be fairly consistent write traffic After some point of time, slapd will then deadlock on shutdown. Or, if allowed to run long enough, it will grind completely to a halt (2-3 weeks, depending on traffic). This started after we upgraded to openssl 1.0.1j. It is continuing to occur with openssl 1.0.2h (just to ntoe). --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#8439) returned unspecified error while trying to start ldap server
by quanah＠zimbra.com 09 Jun '16

09 Jun '16

--On Thursday, June 09, 2016 3:33 PM +0000 sudha243p(a)gmail.com wrote: > Could you please let us know what went wrong in this scenario ? The ITS system is for filing bug reports, not usage questions. Your logs clearly show your database is corrupt: Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: "ou=slsusers,o=ericssonOAM" Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: database "ou=slsusers,o=ericssonOAM": alock package is unstable. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one (type=bdb, suffix="ou=slsusers,o=ericssonOAM"): bi_db_open failed! (-1) Jun 9 15:24:28 SLS001 slapd[3505]: slapd shutdown: initiated This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8439) returned unspecified error while trying to start ldap server
by sudha243p＠gmail.com 09 Jun '16

09 Jun '16

Full_Name: Sudhakar Pittala Version: openldap 2.8 OS: SUSE11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.176.1.87) Hi, We are using a OPEN SUSE 11.4 LINUX OS machine. Initially ldap process was running fine. Recently we have restarted this machine and after restart we have found that ldap service was not running. So I have tried to start/restart ldap server using Yast and command line but couldn't succeed. Output from Yast: /etc/init.d/ldap start returned 1 (unspecified error): Output from command line: SLS001:/etc/init.d # ./ldap restart redirecting to systemctl redirecting to systemctl Shutting down ldap-server done redirecting to systemctl Starting ldap-server failed File /var/log/localmessages shows below entries. Jun 9 15:24:28 SLS001 slapd[3502]: 1.2.36.79672281.1.13.3 (rdnMatch): Jun 9 15:24:28 SLS001 slapd[3502]: 2.5.13.1 (distinguishedNameMatch): Jun 9 15:24:28 SLS001 slapd[3502]: matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $ olcDbIDAssertAuthcDn $ olcRelay $ pwdPolicySubentry $ olcPPolicyDefault $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect $ suseDefaultBase $ suseDefaultTemplate $ suseSecondaryGroup ) ) Jun 9 15:24:28 SLS001 slapd[3502]: 2.5.13.0 (objectIdentifierMatch): Jun 9 15:24:28 SLS001 slapd[3502]: matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) Jun 9 15:24:28 SLS001 slapd[3505]: slapd startup: initiated. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one: starting "cn=config" Jun 9 15:24:28 SLS001 slapd[3505]: config_back_db_open Jun 9 15:24:28 SLS001 slapd[3505]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn=config" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn=schema" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={0}core> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={0}core> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={0}core" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={1}cosine> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={1}cosine> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={1}cosine" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={2}inetorgperson> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={2}inetorgperson> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={2}inetorgperson" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={3}rfc2307bis> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={3}rfc2307bis> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={3}rfc2307bis" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={4}yast> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={4}yast> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={4}yast" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={-1}frontend"D%D Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={0}config" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={1}bdb" Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one: starting "ou=slsusers,o=ericssonOAM"D%D Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: "ou=slsusers,o=ericssonOAM" Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: database "ou=slsusers,o=ericssonOAM": alock package is unstable. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one (type=bdb, suffix="ou=slsusers,o=ericssonOAM"): bi_db_open failed! (-1) Jun 9 15:24:28 SLS001 slapd[3505]: slapd shutdown: initiated Jun 9 15:24:28 SLS001 slapd[3505]: ====> bdb_cache_release_all Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_close: database "ou=slsusers,o=ericssonOAM": alock_close failed Jun 9 15:24:28 SLS001 slapd[3505]: slapd destroy: freeing system resources. Jun 9 15:24:28 SLS001 slapd[3505]: slapd stopped. Jun 9 15:24:28 SLS001 slapd[3505]: daemon: SLPDereg(service:ldap://SLS001.site) failed with -20, cookie = 0 Jun 9 15:24:28 SLS001 slapd[3505]: daemon: SLPDereg(service:ldaps://SLS001.site) failed with -20, cookie = 0 Could you please let us know what went wrong in this scenario ? BR, Sudhakar

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by quanah＠zimbra.com 08 Jun '16

08 Jun '16

--On Thursday, June 09, 2016 1:19 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> In MMR node, when there is > 2 nodes, operations can get sent out >> endlessly. >> >> For example, we see this modification occur at 20160603194926.427963Z > > You seem to have a large clock sync problem. >> >> Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 >> be_modify cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) >> Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, >> cookie=rid=100,sid=003 >> Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x121c8680 >> 20160603194926.417898Z#000000#001#000000 >> Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing >> 0x9403600 20160527111854.508810Z#000000#004#000000 > > How did a CSN from 20160527 get queued on 20160603? Because it had been going around non-stop since 5/27 (5/27 is when I did the modification). --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by hyc＠symas.com 08 Jun '16

08 Jun '16

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > In MMR node, when there is > 2 nodes, operations can get sent out endlessly. > > For example, we see this modification occur at 20160603194926.427963Z You seem to have a large clock sync problem. > > Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 be_modify > cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x121c8680 > 20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x9403600 20160527111854.508810Z#000000#004#000000 How did a CSN from 20160527 get queued on 20160603? > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 > cookie=rid=102,sid=004,csn=20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: dsysyncrep2: rid=102 CSN too old, ignoring > 20160603194926.417898Z#000000#001#000000 > (reqStart=20160603194922.988081Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 > cookie=rid=101,sid=002,csn=20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 CSN too old, ignoring > 20160603194926.417898Z#000000#001#000000 > (reqStart=20160603194931.992576Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=100 > cookie=rid=100,sid=001,csn=20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x120c1c80 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_matchops: skipping original sid > 001 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x93aae80 20160527095853.061949Z#000000#004#000000 And another one. > Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 be_modify > cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x1104d080 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0xac25300 20160527084152.674596Z#000000#004#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 > cookie=rid=102,sid=004,nsn=20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 CSN too old, ignoring > 20160603194926.427963Z#000000#001#000000 > (reqStart=20160603194922.996275Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=100 > cookie=rid=100,sid=001,csn=20160603194926.433237Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x1116e600 > 20160603194926.433237Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_matchops: skipping origil l sid > 001 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 > cookie=rid=101,sid=002 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0xf0cf380 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x122e2cc0 20160527095853.613262Z#000000#004#000000 And another. There are more in the rest of the output you pasted. -- -- 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

Re: (ITS#8433) slapd deadlocks on shutdown in 3+ MMR configuration with active writes
by hyc＠symas.com 08 Jun '16

08 Jun '16

quanah(a)openldap.org wrote: > Full backtrace of all threads: > > > Thread 4 (Thread 0x7f146ac9d700 (LWP 16805)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > No locals. > #1 0x00007f3c70fe8171 in ldap_pvt_thread_cond_wait (cond=0x1fa0038, > mutex=0x1fa0010) at thr_posix.c:277 > No locals. > #2 0x00007f3c70fe63c2 in ldap_pvt_thread_pool_destroy (tpool=0x7618c0 > <connection_pool>, run_pending=1) at tpool.c:817 > pool = 0x1f763c0 > pptr = 0x1f763c0 > pq = 0x1fa0000 > task = 0x7f3c716a61c8 > i = 0 > #3 0x0000000000438967 in slapd_daemon_task (ptr=0x1d7bce8) at daemon.c:2829 > l = 3 > last_idle_check = 1464372736 > ebadf = 0 > tid = 0 > #4 0x00007f3c70552184 in start_thread (arg=0x7f146ac9d700) at > pthread_create.c:312 > __res = <optimized out> > pd = 0x7f146ac9d700 > now = <optimized out> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725667686144, > -1093867468031317215, 0, 0, 139725667686848, 139725667686144, > 1078920827726146337, 1056426161274956577}, > mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = > {prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = <optimized out> > pagesize_m1 = <optimized out> > sp = <optimized out> > freesize = <optimized out> > __PRETTY_FUNCTION__ = "start_thread" > #5 0x00007f3c7027f37d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > No locals. Thread 4 is waiting for the other threads to finish. > > Thread 3 (Thread 0x7f1468498700 (LWP 16810)): > #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 > No locals. > #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x5d36630, buf=0x5a3c057, > len=433) at sockbuf.c:490D0D > __PRETTY_FUNCTION__ = "sb_stream_read" Thread 3 is inside OpenSSL, it thinks there are 433 bytes to read on this socket and it's waiting for them to arrive. There's not much we can do in slapd about this. > #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d36d20, buf=0x5a3c057, > len=433) at sockbuf.c:829 > ret = 79 > ebuf = "PjIh\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\250\062H\004\000\000\000\000'\000\000\000\000\000\000\000\240\361H\004\000\000\000\000P\026u\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\0006364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hxIh\t\000\000\000\300lIh\024\177\000\000\220jIh\024\177\000" > #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x5a93110, > buf=0x5a3c057 "\004\areqType1\b\004\006modify02\004\005reqDN1)\004'uid=gtillman,ou=people,dc=zimbra,dc=com0\201\317\004\006reqMod1\201\304\004:zimbraAuthTokens:- > 1988626989|1464372357970|8.7.0_RC1_1601\004\063entryCSN:= > 20160527182235.762156Z#000000#003#000000\004."..., len=433) at tls_o.c:721 > p = 0x5a6caa0 > ret = 79 > #4 0x00007f3c6f19988b in BIO_read () from > /opt/zimbra/common/lib/libcrypto.so.1.0.0 > No symbol table info available. > #5 0x00007f3c6f501ffc in ssl3_read_n () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #6 0x00007f3c6f503ebf in ssl3_read_bytes () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #7 0x00007f3c6f50033b in ssl3_read () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #8 0x00007f3c7101f093 in tlso_sb_read (sbiod=0x5d382e0, buf=0xcb4f93f, len=8) > at tls_o.c:881 > p = 0x5a6caa0 > ret = 635655159814 > err = 28 > __PRETTY_FUNCTION__ = "tlso_sb_read" > #9 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d37800, buf=0xcb4f93f, len=8) > at sockbuf.c:829 > ret = 0 > ebuf = "\000\000\000\000\000\000\000\000\300\211Ih\024\177\000\000\000\207Ih\024\177\000\000\000\000\000\000\000\000\000\000pmIh\024\177\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\240h%h\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000\000\240mIh\000\000\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\320mIh\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000" > #10 0x00007f3c70dd2291 in ber_int_sb_read (sb=0x5d363c0, buf=0xcb4f93f, len=8) > at sockbuf.c:423 > ret = 0 > __PRETTY_FUNCTION__ = "ber_int_sb_read" > #11 0x00007f3c70dcebbf in ber_get_next (sb=0x5d363c0, len=0x7f1468496f00, > ber=0xcb4f930) at io.c:532 > sblen = 8 > buf = "\000\000\000\000\000\000" > tlen = 0 > __PRETTY_FUNCTION__ = "ber_get_next" > #12 0x00007f3c70fea22f in try_read1msg (ld=0x5d36d50, msgid=3, all=0, > lc=0x3d9b320, result=0x7f1468497190) at result.c:491 > ber = 0xcb4f930 > newmsg = 0x0 > l = 0x0 > prev = 0x0 > id = 0 > tag = 0 > len = 0 > foundit = 0 > lr = 0x0 > tmplr = 0x0 > dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = > 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, > lr_res_errno = 0, > lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, > lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext > = 0x0, lr_prev =x0x0, > lr_next = 0x0} > tmpber = {ber_opts = {lbo_valid = -12608, lbo_options = 474, lbo_debug = > 0}, ber_tag = 5341050, ber_len = 0, ber_usertag = 5014619, ber_buf = 0x0, > ber_ptr = 0x0, ber_end = 0x0, > ber_sos_ptr = 0x574963a4 <error: Cannot access memory at address > 0x574963a4>, ber_rwptr = 0x0, ber_memctx = 0x67} > rc = 0 > refer_cnt = 0 > hadref = 0 > simple_request = 0 > err = 0 > lderr = 0 > __PRETTY_FUNCTION__ = "try_read1msg"A%A#13 0x00007f3c70fe9e53 in > wait4msg (ld=0x5d36d50, msgid=3, all=0, timeout=0x7f14684971f0, > result=0x7f1468497190) at result.c:362 > lnext = 0x0 > serviced = 1 > lc_ready = 1 > rc = -2 > tv = {tv_sec = 0, tv_usec = 0} > tv0 = {tv_sec = 0, tv_usec = 0} > start_time_tv = {tv_sec = 1464427439, tv_usec = 944352} > tvp = 0x7f14684970a0 > lc = 0x3d9b320 > __PRETTY_FUNCTION__ = "wait4msg" > #14 0x00007f3c70fe9574 in ldap_result (ld=0x5d36d50, msgid=3, all=0, > timeout=0x7f14684971f0, result=0x7f1468497190) at result.c:117 > rc = 0 > __PRETTY_FUNCTION__ = "ldap_result" > #15 0x00000000004bd6b2 in do_syncrep2 (op=0x7f1468497720, si=0x1dacec0) at > syncrepl.c:841 > Thread 2 (Thread 0x7f1467c97700 (LWP 16812)): > #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 > No locals. > #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x3dac8b0, buf=0x23cc1a8, > len=96) at sockbuf.c:493 > __PRETTY_FUNCTION__ = "sb_stream_read" > #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x3dac850, buf=0x23cc1a8, len=96) > at sockbuf.c:829 > ret = 416 > ebuf = "PZ\311g\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\230\264\343\005\000\000\000\000'\000\000\000\000\000\000\000P~\344\005\000\000\000\000@C5Cru\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\000\364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hh\311g\n\000\000\000\300\\\311g\024\177\000\000\220Z\311g\024\177\000" > #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x244b2d0, > buf=0x23cc1a8 "\240F0D\004\030\061.3.6.1.4.1.4203.1.9.1.2\004(0&\n\001\001\004\020\004@\320&\270\206\020\065\223\244\347B\322ף\327\004\017rid=102,sid=001췫\272\005\324a`\346\343\373\335\062\065\223\a\363\363Sv\003\003\003\003\063.1.9.1.2\004(0&\n\001\001\004\020\003\362\377\004\270\206\020\065\223\236\347B\322ף\327\004\017rid=102,sid=001\027ל{\026g\264\262\210\331U]\330#\020u\241ʂ\206\b\b\b\b\b\b\b\b\bntryCSN:= > 20160527182329"..., len=96% a at tls_o.c:721 > p = 0x3da51e0 > ret = 416 > #4 0x00007f3c6f19988b in BIO_read () from > /opt/zimbra/common/lib/libcrypto.so.1.0.0 > No symbol table info available. Thread 2 is in the same state as thread 3. -- -- 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

Re: (ITS#8434) Config entry cleanup on Add should be run unconditionally
by hyc＠symas.com 08 Jun '16

08 Jun '16

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:c7f:221f:c00:a3e:8eff:fe52:dac5) > > > With cn=config the ConfigLDAPadd function might have to allocate resources that > are needed by the time the attributes/config directives are being processed > since there is no indication which directives there are and what order they come > in. When using LDAPAdd, attributes are processed in the order of their schema definitions. > If any of the config values fail validation, the configuration code has to react > and clean up - which is possible using ca->cleanup. No, that's not its purpose. If anything fails, the entire config entry must be wiped out. LDAPAdd is all-or-nothing. > While Modify handling (config_modify_internal) already calls ca->cleanup in each > case, this is not true for config_add_internal, there it is only run on success. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2016