openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#7034) Patch - Mozilla NSS - SSL_ForceHandshake not thread safe with PEM module
by rmeggins＠redhat.com 06 Sep '11

06 Sep '11

Full_Name: Rich Megginson Version: current tip of master branch OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-use-mutex-for-connection-handshake-whe… Submission from: (NULL) (76.26.104.137) The establishment of the TLS/SSL connection (accept or connect) using SSL_ForceHandshake() is not thread safe when using the PEM module. This patch adds a mutex to protect the call. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7033) suffix invalid dn :21
by Pierangelo Masarati 06 Sep '11

06 Sep '11

The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. Nothing in your report is indicative of a bug in OpenLDAP. If you have questions about use of OpenLDAP Software which are not answered in the documentation, FAQ, and archives, use the OpenLDAP-technical list (subscription required; instructions here <http://www.openldap.org/lists/mm/listinfo/openldap-technical>). This issue report will be closed. p.

1 0

(ITS#7033) suffix invalid dn :21
by mvraobadri＠gmail.com 06 Sep '11

06 Sep '11

Full_Name: veerabhadrarao Version: 2.4.24 OS: solaris10 (9/10) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (223.177.104.45) Dear sir, i m configure the open ldap server in my solaris10(9/10). but i run the slapd -T test command one error message is coming i.e suffix invalid dn:21.please help how to rectify this error. Regrads veerabhadrao

1 0

Re: (ITS#7032) LDAP Server not answering a request
by quanah＠zimbra.com 05 Sep '11

05 Sep '11

--On Wednesday, August 31, 2011 5:24 PM +0000 pantelis.petridis(a)yahoo.com wrote: > Do you have some information about what happened? Is there any > explanation why the LDAP Server does not answer an LDAP request? Is there > a workaround? Please confirm whether or not the issue exists in the current OpenLDAP release (2.4.26). Thanks! --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#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 05 Sep '11

05 Sep '11

Hello, Two packages have been uploaded to the incoming folder on openldap's public ftp site. The package names are: fortressCore.zip and fortressRealm.zip of sizes 1.1 MB and 74.8 KB respectively. The two packages contain the source code that form the basis for the Fortress Java SDK (fortessCore) and Java EE container security plug-in component (fortressRealm). Thanks, Shawn

1 0

(ITS#7032) LDAP Server not answering a request
by pantelis.petridis＠yahoo.com 31 Aug '11

31 Aug '11

Full_Name: Pantelis Petridis Version: 2.4.23 OS: RedHat Enterprise Linux 4 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) I am using OpenLDAP 2.4.23 with the Oracle Berkeley DB backend. After a few hours the OpenLDAP stops answering an ldapsearch request. The OpenLDAP server is blocking when I execute a command like the following: -> Monitor backend ldapsearch -H "ldap://127.0.0.1:/1390/" -D cn=monitoring,cn=Monitor -W -b "cn=Current,cn=Connections,cn=Monitor" -x -s sub '*' '+' or -> BDB backend ldapsearch -H "ldap://127.0.0.1:/1390/" -D cn=Resources -W -b "cn=Resources" -x -s sub I can see with top -Hp <pid of slapd> that one thread is working 100%. With kill -11 I created a corefile and I found out that the thread is in the cache.c file in line 1367. That is the while loop in back-bdb\cache.c while ( busy ) { ldap_pvt_thread_yield(); busy = 0; bdb_cache_entryinfo_lock( ei ); if (( ei->bei_state & ( CACHE_ENTRY_NOT_LINKED | CACHE_ENTRY_LOADING | CACHE_ENTRY_ONELEVEL )) || ei->bei_finders > 0 ) busy = 1; bdb_cache_entryinfo_unlock( ei ); } It seems that the entry ei can not be deleted from the cache. I tried also to kill the slapd with executing the following command (many times) kill <pid of slapd> but it did not work. Only kill -9 <pid of slapd> killed the slapd process. Do you have some information about what happened? Is there any explanation why the LDAP Server does not answer an LDAP request? Is there a workaround? BR Pantelis

1 0

Re: (ITS#7013) OpenLDAP freezes and doesn't respond
by cgrosjean＠janua.fr 29 Aug '11

29 Aug '11

Thank you for your answer. We actually could not wait for a solution or workaround anymore, due to the project planning and the time we spent trying to find a solution with OpenLDAP. So, we decided to test replacing OpenLDAP by OpenDJ, and the tests give pretty good results: we don't have the problem anymore. Howard Chu a écrit : > cgrosjean(a)janua.fr wrote: >> Full_Name: Cyril Grosjean >> Version: 2.4.26 >> OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.66.198.206) >> >> >> My OpenLDAP server freezes, after a few requests, and I can't >> understand why. >> I have a few LDAP clients (ldapsearch, a custom Java app. and >> ApacheDirectoryStudio), running from different systems, either >> locally on the >> OpenLDAP server, or on another OpenLDAP server, or on a remote >> workstation, and >> none manages to get an answer from OpenLDAP. The connection is >> established but >> each client gets stuck waiting for any result. >> >> We can reproduce the freeze, after a few requests coming from the >> custom Java >> application. The problem doesn't occur if we don't use that application. >> >> >> The last time, it occured only a few minutes after the OpenLDAP >> daemon was >> restarted, under very low load. >> I use OpenLDAP 2.4.26, over Red Hat Enterprise Linux Server release 5.4 >> (Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over >> VMWare. >> I also use BDB 4.8.30, and OpenLDAP's been compiled with the >> following options: >> >> ./configure --prefix=/opt/openldap-2.4.26 --enable-dynamic=yes >> --enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes >> --enable-accesslog=yes --enable-sssvlv=yes >> >> I noticed only 60 to 70 established connections on port 389 >> (according to >> netstat) when the freeze occurs. >> >> The OpenLDAP server is set in syncrepl mirror mode replication, and >> the other >> OpenLDAP server (only used as a hot stand-by) works fine (but doesn't >> receive >> any load). However, one can reproduce the problem with replication >> disabled. > > Looks like you have a thread blocked trying to modify a record, while > all the other writer threads are blocked waiting for that writer to > complete. The output of db_stat -CA would help to indicate why the > writer is blocked. > > It also looks like you've configured your replication with mirrormode > and delta-syncrepl. This combination is not yet supported in OpenLDAP, > certainly not in 2.4.26. It may be supported in 2.4.27, depending on > how our ongoing testing turns out. >

1 0

Re: (ITS#7013) OpenLDAP freezes and doesn't respond
by hyc＠symas.com 27 Aug '11

27 Aug '11

cgrosjean(a)janua.fr wrote: > Full_Name: Cyril Grosjean > Version: 2.4.26 > OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.66.198.206) > > > My OpenLDAP server freezes, after a few requests, and I can't understand why. > I have a few LDAP clients (ldapsearch, a custom Java app. and > ApacheDirectoryStudio), running from different systems, either locally on the > OpenLDAP server, or on another OpenLDAP server, or on a remote workstation, and > none manages to get an answer from OpenLDAP. The connection is established but > each client gets stuck waiting for any result. > > We can reproduce the freeze, after a few requests coming from the custom Java > application. The problem doesn't occur if we don't use that application. > > > The last time, it occured only a few minutes after the OpenLDAP daemon was > restarted, under very low load. > I use OpenLDAP 2.4.26, over Red Hat Enterprise Linux Server release 5.4 > (Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over VMWare. > I also use BDB 4.8.30, and OpenLDAP's been compiled with the following options: > > ./configure --prefix=/opt/openldap-2.4.26 --enable-dynamic=yes > --enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes > --enable-accesslog=yes --enable-sssvlv=yes > > I noticed only 60 to 70 established connections on port 389 (according to > netstat) when the freeze occurs. > > The OpenLDAP server is set in syncrepl mirror mode replication, and the other > OpenLDAP server (only used as a hot stand-by) works fine (but doesn't receive > any load). However, one can reproduce the problem with replication disabled. Looks like you have a thread blocked trying to modify a record, while all the other writer threads are blocked waiting for that writer to complete. The output of db_stat -CA would help to indicate why the writer is blocked. It also looks like you've configured your replication with mirrormode and delta-syncrepl. This combination is not yet supported in OpenLDAP, certainly not in 2.4.26. It may be supported in 2.4.27, depending on how our ongoing testing turns out. -- -- 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#7031) delta-syncrepl MMR abort on delete
by quanah＠OpenLDAP.org 26 Aug '11

26 Aug '11

Full_Name: Quanah Gibson-Mount Version: 2.4.26 + delta-sync MMR OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Thread 1 (Thread 13679): #0 0x00007f0e938d0a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f0e938d45c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f0e938c9941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00000000004b1449 in modify_delete_vindex (e=0x7f0e8252e8f0, mod=0x4c06050, permissive=0, text=0x7f0e8252ee50, textbuf=0x7f0e8252ea20 "", textlen=256, idx=0x0) at mods.c:234 a = 0x7f0e8252e780 mr = 0x1e3abb0 cvals = 0x7f0e8252e780 id2 = 0x0 rc = 0 i = 2 j = 188672704 flags = 32526 dummy = 0 '\000' __PRETTY_FUNCTION__ = "modify_delete_vindex" #4 0x00000000004b1309 in modify_delete_values (e=0x7f0e8252e8f0, m=0x4c06050, perm=0, text=0x7f0e8252ee50, textbuf=0x7f0e8252ea20 "", textlen=256) at mods.c:189 No locals. #5 0x00007f0e903e4f52 in hdb_modify_internal (op=0x7f0e8252f440, tid=0x23252c0, modlist=0x4c06050, e=0x7f0e8252e8f0, text=0x7f0e8252ee50, textbuf=0x7f0e8252ea20 "", textlen=256) at modify.c:226 rc = 32526 err = -2108495040 mod = 0x4c06050 ml = 0x4c06050 save_attrs = 0x44b58b8 ap = 0x7f0e8252e9e0 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "hdb_modify_internal" #6 0x00007f0e903e68a2 in hdb_modify (op=0x7f0e8252f440, rs=0x7f0e8252ee30) at modify.c:638 bdb = 0x232fc00 e = 0x43a6e08 ei = 0xb3bc990 manageDSAit = 2 textbuf = '\000' <repeats 66 times>, "\001", '\000' <repeats 15 times>, "\002", '\000' <repeats 21 times>"\370, \366R\202\016\177", '\000' <repeats 26 times>, "\t\000\000\000\000\000\000\000\300G-\002\000\000\000\000\t\000\000\000\000\000\000\000\240G-\002", '\000' <repeats 36 times>"\240, b\300\004", '\000' <repeats 12 times>, "(\000\000\000\000\000\000\000\240\342<\v", '\000' <repeats 12 times>"\300, \356R\202\016\177\000\000\000\000\000\000\000\000\000" textlen = 256 ltid = 0x2325420 lt2 = 0x23252c0 opinfo = {boi_oe = {oe_next = {sle_next = 0x7f0e8252eec0}, oe_key = 0x232fc00}, boi_txn = 0x2325420, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 221, e_name = {bv_len = 71, bv_val = 0xb33e140 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, e_nname = {bv_len = 71, bv_val = 0xb3d4f00 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, e_attrs = 0x44b8b80, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0xb3bc990} lock = {off = 2387032, ndx = 831, gen = 92, mode = DB_LOCK_READ} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x7f0e95277f6a, 0x0, 0x7f0e8252ea00, 0x7f0e8252eab0, 0x44b8d88} num_ctrls = 0 rc = 0 #7 0x00000000004d3324 in overlay_op_walk (op=0x7f0e8252f440, rs=0x7f0e8252ee30, which=op_modify, oi=0x1ec3c00, on=0x0) at backover.c:671 func = 0x7f0e9060c018 rc = 32768 #8 0x00000000004d3562 in over_op_func (op=0x7f0e8252f440, rs=0x7f0e8252ee30, which=op_modify) at backover.c:723 oi = 0x1ec3c00 on = 0x1eb8e00 be = 0x2338e00 db = {bd_info = 0x7f0e9060bfc0, bd_self = 0x2338e00, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 39176, 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 = 0x22d03a0, be_nsuffix = 0x22d0360, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x22d47c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x22d47a0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x22f2620, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x3b04710, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x1e82580, be_pb = 0x0, be_cf_ocs = 0x7f0e9060bd20, be_private = 0x232fc00, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f0e8252eea0, sc_response = 0x4d205c <over_back_response>, sc_cleanup = 0, sc_private = 0x1ec3c00} sc = 0x795277e25 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #9 0x00000000004d36cd in over_op_modify (op=0x7f0e8252f440, rs=0x7f0e8252ee30) at backover.c:762 No locals. #10 0x00000000004c0061 in syncrepl_message_to_op (si=0x1e82580, op=0x7f0e8252f440, msg=0x4e9bf80) at syncrepl.c:2306 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4bf0ba}, oe_si = 0x1e82580} ber = 0xb3c9e60 modlist = 0x1f10b00 ls = 0x75d2c0 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_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x4c06270, sc_response = 0x4c740b <null_callback>, sc_cleanup = 0, sc_private = 0x0} text = 0x0 txtbuf = '\000' <repeats 16 times>, "p\360R\202\016\177", '\000' <repeats 18 times>, "\001", '\000' <repeats 23 times>"\330, @!\002", '\000' <repeats 12 times>"\330, @!\002\000\000\000\000\300\360R\202\016\177", '\000' <repeats 34 times>, "\n\000\000\000\000\000\000\000p\303\343\001\000\000\000\000\300\352\341\001\000\000\000\000\371\377\377\377\377\377\377\377\020\361R\202\016\177\000\000R(\222\223\016\177\000\000\000\000\000\000\000\000\000\000\200\277\351\004\000\000\000\000\360\360R\202\016\177", '\000' <repeats 18 times>"\277, \212'\225\016\177\000\000\300\037\361\001", '\000' <repeats 12 times>, "`\255;\v\000\000\000\000@\370\341\004\000\000\000" textlen = 256 bdn = {bv_len = 71, bv_val = 0xb3a94db "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} dn = {bv_len = 71, bv_val = 0x4c06548 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} ndn = {bv_len = 71, bv_val = 0x4c06658 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0xb3dd5e0 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #11 0x00000000004bb1e6 in do_syncrep2 (op=0x7f0e8252f440, si=0x1e82580) at syncrepl.c:986 match = 0 cookie = {bv_len = 60, bv_val = 0x4e53679 "rid=100,sid=002,csn=20110826222451.030140Z#000000#002#000000"} rctrls = 0xb3ac880 rctrlp = 0x4e526e0 syncUUIDs = 0x7f0e8252f2b0 bdn = {bv_len = 44, bv_val = 0xb3a9489 "reqStart=20110826222451.000005Z,cn=accesslog"} syncUUID = {bv_len = 16, bv_val = 0x4e53667 "\365\212\264\030d}\020\060\235\364\351P\032\274\311v"} si_tag = 7499012898816 entry = 0x7f0e8252f220 punlock = 0 syncstate = 1 retdata = 0x100000 retoid = 0x38 <Address 0x38 out of bounds> len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "`6\345\004\000\000\000\000\265\066\345\004\000\000\000\000\265\066\345\004", '\000' <repeats 28 times>, "@\363R\202\016\177\000\000\271\060I\225\016\177\000\000@\363R\202\016\177\000\000@\361u\000\000\000\000\000@\363R\202\016\177\000\000\343\210E\000\000\000\000\000X\364R\202\016\177\000\000\271\060I\225\016\177\000\000\220\363R\202\016\177\000\000\020`\343\004\000\000\000\000\320\363R\202\016\177\000\000\006\201K\225\016\177\000\000@\364R\202\016\177\000\000\064\364R\202\016\177\000\000\000\000\000\000\001\000\000\000\000\206\260\003\000\000\000\000\320\363R\202\016\177\000\000@\364R\202\016\177\000\000\320\363R\202\016\177\000\000\371\360C\000\000\000\000\000\320\363R\202\016\177\000\000\b`\343\004\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7f0e8252f2b0 msg = 0x4e9bf80 syncCookie = {ctxcsn = 0xb3bad60, sids = 0xb335cb8, numcsns = 1, rid = 100, octet_str = {bv_len = 60, bv_val = 0x4e9b9c0 "rid=100,sid=002,csn=20110826222451.030140Z#000000#002#000000"}, sid = 2, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x2296cc0, sids = 0x6f33730, numcsns = 3, rid = 100, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 0 tout_p = 0x7f0e8252f1f0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #12 0x00000000004bd3ed in do_syncrepl (ctx=0x7f0e8252fb50, arg=0x1e1fe10) at syncrepl.c:1519 rtask = 0x1e1fe10 si = 0x1e82580 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9910 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9910 ""}, c_listener = 0x5016a0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_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}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x453e95 <slap_send_ldap_result>, c_send_search_entry = 0x454b9d <slap_send_search_entry>, c_send_search_reference = 0x457084 <slap_send_search_reference>, c_send_ldap_extended = 0x4546fc <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x45497a <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f0e8252f5b0, o_tag = 102, o_time = 1314397491, o_tincr = 51, o_bd = 0x7f0e8252ec20, o_req_dn = {bv_len = 71, bv_val = 0xb3c9cd0 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, o_req_ndn = {bv_len = 71, bv_val = 0xb3c9c30 "uid=test.1314397491499.845,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, o_request = {oq_add = {rs_modlist = 0x4c06050, rs_e = 0x1}, oq_bind = { rb_method = 79716432, rb_cred = {bv_len = 1, 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 = 0x4c06050}, oq_modify = {rs_mods = {rs_modlist = 0x4c06050, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x4c06050, rs_no_opattrs = 1 '\001'}, 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 = 79716432, rs_deref = 0, rs_slimit = 1, 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 = 79716432}, oq_cancel = {rs_msgid = 79716432}, oq_extended = {rs_reqoid = {bv_len = 79716432, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 79716432, bv_val = 0x1 <Address 0x1 out of bounds>}, 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 = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7f0e8252f6f8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x22d47c0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x22d47a0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x4c062a0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0xb3ce2a0 "20110826222451.030140Z#000000#002#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7f0e8252e970}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 100, oh_conn = 0x7f0e8252f800, oh_msgid = 0, oh_protocol = 0, oh_tid = 139700292749056, oh_threadctx = 0x7f0e8252fb50, oh_tmpmemctx = 0x22802c0, oh_tmpmfuncs = 0x75d220, oh_counters = 0x7a01e0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 16 times>, 0x7f0e8252f180, 0x0 <repeats 15 times>}} op = 0x7f0e8252f440 rc = 0 dostop = 0 s = 22 i = 1 defer = 1 fail = 0 freeinfo = 0 be = 0x2338e00 #13 0x000000000043d1f5 in connection_read_thread (ctx=0x7f0e8252fb50, argv=0x16) at connection.c:1276 rc = 0 cri = {op = 0x0, func = 0x4bcdea <do_syncrepl>, arg = 0x1e1fe10, ctx = 0x7f0e8252fb50, nullop = 0} s = 22 #14 0x00007f0e95491b29 in ldap_int_thread_pool_wrapper (xpool=0x1e2b1c0) at tpool.c:685 pool = 0x1e2b1c0 task = 0x436f440 work_list = 0x1e2b258 ctx = {ltu_id = 139700292749056, ltu_key = {{ltk_key = 0x4b2102, ltk_data = 0x22802c0, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x248d000, ltk_data = 0x22da6e0, ltk_free = 0x7f0e90401b0f <bdb_reader_free>}, {ltk_key = 0x21f8800, ltk_data = 0x22da840, ltk_free = 0x7f0e90401b0f <bdb_reader_free>}, {ltk_key = 0x43c795, ltk_data = 0x22d8100, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x458555, ltk_data = 0x4e4c800, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x4e6f600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 905 hash = 3138887561 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f0e94aa49ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #16 0x00007f0e9398370d in clone () from /lib/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available.

1 0

Possible memory leak?
by Thomas Rasmussen 26 Aug '11

26 Aug '11

Hello I have an openldap installation setup which appears to have a memory leak which I have not been able to solve by upgrading software etc. which is why I'm submitting this, if this is the wrong list, please let me know. The setup is: - OpenLDAP server running 2.4.26, compiled against db-5.2.28, heimdal 1.2.1. - Server is SunOS servername 5.10 Generic_141445-09 i86pc i386 i86pc, 6GB of RAM and 5GB of swap (in a VMWare ESX environment) I have the following in my DB_CONFIG file: set_cachesize 0 52428800 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /pack/openldap/var/openldap-crl-logs In my slapd.conf I have the following entries (I stripped out some restricts and other irrelevant lines) include /pack/openldap/etc/openldap/schema/core.schema include /pack/openldap/etc/openldap/schema/entrust.attributes.cfg include /pack/openldap/etc/openldap/schema/entrust.objectclasses.cfg idletimeout 300 pidfile /pack/openldap/var/run/slapd-crl.pid argsfile /pack/openldap/var/run/slapd-crl.args threads 4 database bdb suffix "c=DK" directory /pack/openldap/var/openldap-crl index objectClass,entryCSN,entryUUID eq checkpoint 128 1 dbnosync overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 2 monitoring off idletimeout 10 Just FYI, the server is a clone of another server currently running syncprov replication between two nodes, hence the syncprov lines. This server has the same databases as the production ones, but I just moved it to isolated area and removed all sync options from slapd. My database is rather big: vs24n02z2.prl1:/pack/openldap/var/openldap-crl root$ du -sh *.bdb 961M dn2id.bdb 162M entryCSN.bdb 67M entryUUID.bdb 10G id2entry.bdb 4.0M objectClass.bdb but I'd imagine this not beeing a problem (other than some performance issues, but this is not the problem here). Now, when I start up my slapd, it consumes around 6MB RAM, all is fine, I can perform searches and updates without problems. But my memory consumption is going through the roof! If I perform a search through the part of the database having alot of data, I suddenly find slapd using 500+ MB of memory... In our production setup, we actually see that after a couple of weeks, slapd is consuming 3+ GB of memory, and then at some point hits a Out of memory, and crashes. Our production setup is infact a openldap 2.4.22 with berkeley db 4.6.21, and my test server (cloned in a vmware environment) has just upgraded this environment by this recipe: Using db-4.6.21 * db_checkpoint -1 * db_recover -h <path to bdb files> install db-5.2.28 * Loop through all bdb files: db_upgrade <bdb file> * install openldap 2.4.26 (compiled against db-5.2.28) * start slapd The server which updates the LDAP is performing many search and updates, which is probably why memory consumption is exploding after restarts? Now, my main concern is, how (if possible) can we procede with this? We really need to find the problem as this causes production problems whenever the ldap crashes. Regards Thomas

2 1

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