openldap-bugs July 2012

openldap-bugs@openldap.org

19 participants
47 discussions

(ITS#7326) [PATCH] use AI_ADDRCONFIG if defined in the environment
by jvcelak＠redhat.com 19 Jul '12

19 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120719-use-ai-addrconfig-if-defin… Submission from: (NULL) (209.132.186.34) Use AI_ADDRCONFIG flag with getaddrinfo() if the symbol is defined. I think that no configure macro is needed for this. The symbol should be present on the systems which support it. And I believe we can enforce this flag if available. The attached file is 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, Jan Vcelak 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#7325) Panic issue with slapd-perl
by hyc＠symas.com 19 Jul '12

19 Jul '12

aescanero(a)gmail.com wrote: > Full_Name: Alejandro Escanero Blanco > Version: 2.4.31 > OS: RHEL 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.12.24.133) > > > After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function > in the perl module with this error: > panic: sv_setpvn called with negative strlen, <DATA> line 275 > > Back to 2.4.21 and perl module is running ok. > > A fix is now in git master, please test and report back. Revision 348d43e. -- -- 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#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

The problem was in the perl module with a uninitialized value, in 2.4.21 give the error Use of uninitialized value in concatenation (.) or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 but in 2.4.31 give me a panic. -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

(ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

Full_Name: Alejandro Escanero Blanco Version: 2.4.31 OS: RHEL 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.12.24.133) After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function in the perl module with this error: panic: sv_setpvn called with negative strlen, <DATA> line 275 Back to 2.4.21 and perl module is running ok.

1 0

(ITS#7324) [PATCH] autoconf: use pkg-config to detect Mozilla NSS library
by jvcelak＠redhat.com 18 Jul '12

18 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120718-configure-use-pkg-config-f… Submission from: (NULL) (209.132.186.34) Hello, this patch is just a proposal. It enables pkg-config to detect correct compilation flags for Mozilla NSS crypto backend. I believe this should be adapted also for other dependencies (which support it) instead of hardcoding the flags into the configure script. We might get rid of problems caused by differences between the individual environments (and distributions in case of Linux). Jan The attached file is 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, Jan Vcelak 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#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 18 Jul '12

18 Jul '12

Hi, I had some difficulties to reproduce it, but I have finally succeeded : [Switching to Thread 0x431e4940 (LWP 11061)] 0x000000000054211c in sp_avl_cmp (c1=<value optimized out>, c2=0xbfb5a60) at syncprov.c:378 378 rc = m1->mt_op->o_req_ndn.bv_len - m2->mt_op->o_req_ndn.bv_len; Thank you for the help, David Coutadeur Le 17/07/2012 19:59, Quanah Gibson-Mount a écrit : > --On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com > wrote: > >> >> Hi everybody, >> >> Does anybody have some news about this ticket ? Is it still valid, or >> maybe is it already solved as a side effect ? >> >> Thanks for any reply, > > Can you reproduce it with current RE24 code from git? > > --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#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 18 Jul '12

18 Jul '12

Do we want to document this or change behavior?

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 17 Jul '12

17 Jul '12

--On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com wrote: > > Hi everybody, > > Does anybody have some news about this ticket ? Is it still valid, or > maybe is it already solved as a side effect ? > > Thanks for any reply, Can you reproduce it with current RE24 code from git? --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#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 17 Jul '12

17 Jul '12

Hi everybody, Does anybody have some news about this ticket ? Is it still valid, or maybe is it already solved as a side effect ? Thanks for any reply, D.C. Le 16/03/2012 19:40, David Coutadeur a écrit : > > Hi, > > I finally had the opportunity to get a valgrind analysis of my problem. > You can find it below. Thank you for any help. > > D. > > > > ==19496== 12 bytes in 1 blocks are definitely lost in loss record 16 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x80E0297: do_syncrepl (syncrepl.c:706) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 155 (32 direct, 123 indirect) bytes in 1 blocks are definitely > lost in loss record 47 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x4057054: ber_bvarray_dup_x (memory.c:756) > ==19496== by 0x80E0212: do_syncrepl (syncrepl.c:699) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 270 (228 direct, 42 indirect) bytes in 3 blocks are definitely > lost in loss record 49 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x8195E91: syncprov_op_search (syncprov.c:2473) > ==19496== by 0x80E3333: overlay_op_walk (backover.c:661) > ==19496== by 0x80E3A09: over_op_func (backover.c:723) > ==19496== by 0x807BE85: fe_op_search (search.c:402) > ==19496== by 0x807C772: do_search (search.c:247) > ==19496== by 0x807988B: connection_operation (connection.c:1150) > ==19496== by 0x807A0FC: connection_read_thread (connection.c:1286) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > > > > > > Le 20/02/2012 10:32, David Coutadeur a écrit : >> >> Hi, >> >> Concerning the cpu : >> model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz >> However, OpenLDAP is used in a virtual machine, with only one dedicated >> core. This is 32 bits version of OpenLDAP, on a 32 bits OS. >> Linux OS : >> Red Hat Enterprise Linux Server release 5.7 (Tikanga) >> kernel : >> 2 2.6.18-274.3.1.el5 >> >> You can get the server configuration below. >> >> Concerning the client, you can find the source code here : >> http://loadtesting.sourceforge.net/index.php?lang=en >> >> >> >> # >> ---------------------------------------------------------------------------- >> # Global section >> # >> ---------------------------------------------------------------------------- >> >> sizelimit 15000 >> >> allow bind_v2 >> password-hash {SSHA} >> threads 8 >> loglevel 256 >> >> serverID 2 >> >> include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf >> >> pidfile /opt/openldap/var/run/slapd.pid >> argsfile /opt/openldap/var/run/slapd.args >> >> # ACLs definition (cutted here) >> >> ####################################################################### >> # SSL definitions >> ####################################################################### >> # Definition of cert files >> # --------------------------------- >> TLSCipherSuite HIGH:MEDIUM:+SSLv2 >> >> TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert >> TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert >> TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key >> >> TLSVerifyClient never >> >> >> >> ####################################################################### >> # BDB database definitions >> ####################################################################### >> database monitor >> >> ####################################################################### >> # suffix dc=example,dc=com >> # -------------------- >> ####################################################################### >> database bdb >> directory /opt/openldap/var/openldap-data >> # some indexes >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "dc=example,dc=com" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 60000 >> dncachesize 60000 >> idlcachesize 60000 >> cachefree 100 >> >> rootdn "cn=Manager,dc=example,dc=com" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> # >> ---------------------------------------------------------------------------- >> # REPLICATION definitions >> # >> ---------------------------------------------------------------------------- >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=001 >> provider=ldap://ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="dc=example,dc=com" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> >> # >> ---------------------------------------------------------------------------- >> # limits >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> ####################################################################### >> # suffix o=edition >> # ---------------- >> ####################################################################### >> database bdb >> >> directory /opt/openldap/var/openldap-data-edition >> # some indexes >> >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "o=edition" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 50000 >> dncachesize 50000 >> idlcachesize 50000 >> cachefree 100 >> >> >> >> # >> ---------------------------------------------------------------------------- >> # rootdn >> # >> ---------------------------------------------------------------------------- >> # Cleartext passwords, especially for the rootdn, should >> # be avoid. See slappasswd(8) and slapd.conf(5) for details. >> # Use of strong authentication encouraged. >> rootdn "cn=Manager,o=edition" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> ####################################################################### >> # REPLICATION definitions >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=002 >> provider=ldap://vspar-ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="o=edition" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> # >> ---------------------------------------------------------------------------- >> # Limits for current BDB >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> >> >> >> Le 17/02/2012 19:00, Howard Chu a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> Full_Name: dcoutadeur >>>> Version: 2.4.28 >>>> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (109.197.176.10) >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >>>> tests, each >>>> interrupted by Ctrl+C. (see what's a test below) >>>> The segfault is also reproduced in version 2.4.28. >>>> >>>> I think I won't be able to reproduce the bug with Valgrind. >>> >>> If you expect us to try to reproduce the bug, you'll have to provide >>> more information. Since this crash is in syncprov there's obviously at >>> least two servers involved; what are their configurations? What hardware >>> are they running on (in particular, how many CPU cores per server)? >>> Since you're using a custom client, can you provide the client source code? >>>> >>>> Thank you in advance for any help. >>>> >>>> D. >>>> >>>> >>>> Note : A test is 100 times 100 threads, each doing a bind, an add, a >>>> modify, a >>>> delete, and a logout. >>>> >>>> >>>> >>>> >>>> >>>> (gdb) bt full >>>> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >>>> rc =<value optimized out> >>>> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >>>> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >>>> p =<value optimized out> >>>> q =<value optimized out> >>>> r =<value optimized out> >>>> top =<value optimized out> >>>> side =<value optimized out> >>>> side_bf =<value optimized out> >>>> shorter =<value optimized out> >>>> nside =<value optimized out> >>>> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >>>> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >>>> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >>>> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >>>> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >>>> 0x823c27} >>>> pdir = >>>> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >>>> >>>> depth = 0 >>>> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >>>> syncprov.c:1401 >>>> cb = 0x8cb91258 >>>> opc = 0x8cb91268 >>>> si = 0xa255610 >>>> sm = 0xa255688 >>>> snext =<value optimized out> >>>> mt = 0x8b4004c8 >>>> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >>>> result.c:541 >>>> sc_next = 0x8d994dec >>>> sc = 0x8cb91258 >>>> scp = 0x8d994928 >>>> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >>>> result.c:733 >>>> berbuf = { >>>> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >>>> '\000'<repeats 12 times>, >>>> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >>>> >>>> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >>>> >>>> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >>>> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >>>> dalign = 5.4323095486619588e-312, >>>> palign = 0x10000<Address 0x10000 out of bounds>} >>>> ber =<value optimized out> >>>> rc = 32768 >>>> bytes = 14 >>>> __PRETTY_FUNCTION__ = "send_ldap_response" >>>> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >>>> result.c:860 >>>> tmp = 0x0 >>>> otext = 0x0 >>>> oref = 0x0 >>>> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >>>> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >>>> pdn = {bv_len = 23, bv_val = 0x8b40372f >>>> "ou=people,dc=afp,dc=com"} >>>> p = 0x8fc4c0fc >>>> oe = 0x8fc4c804 >>>> ei = 0xa37d1c8 >>>> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >>>> times>, "\001", '\000'<repeats 198 times> >>>> children = 0xa223b20 >>>> entry = 0xa223980 >>>> ltid = 0x0 >>>> lt2 = 0x8b402bf0 >>>> eid = 57976 >>>> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >>>> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >>>> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >>>> lock = {off = 133260, ndx = 772, gen = 2004, mode = >>>> DB_LOCK_READ} >>>> num_retries = 0 >>>> success = 0 >>>> postread_ctrl = 0x0 >>>> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >>>> num_ctrls = 0 >>>> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >>>> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >>>> rc = 32768 >>>> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >>>> which=op_add) at backover.c:723 >>>> oi = 0xa254ff0 >>>> on = 0xa255508 >>>> be = 0xa252560 >>>> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >>>> be_ctrls = >>>> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >>>> >>>> be_flags = 563464, 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 = >>>> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >>>> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >>>> bv_val = 0x0}, be_rootdn = {bv_len = 24, >>>> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >>>> {bv_len = 24, >>>> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >>>> {bv_len = 38, >>>> bv_val = 0xa2876f0 >>>> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >>>> be_def_limit = { >>>> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >>>> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >>>> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >>>> 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = >>>> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >>>> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >>>> __size = '\000'<repeats 23 times>, __align = 0}, >>>> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >>>> be_private = 0xa252660, be_next = { >>>> stqe_next = 0xa288538}} >>>> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >>>> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >>>> sc =<value optimized out> >>>> rc =<value optimized out> >>>> __PRETTY_FUNCTION__ = "over_op_func" >>>> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >>>> repl_user = 0 >>>> rc =<value optimized out> >>>> bd = 0x82234c0 >>>> textbuf = >>>> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >>>> >>>> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >>>> >>>> .\"\b\314h\032\216\030O\231\215\245\063\b\b >>>> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >>>> >>>> __PRETTY_FUNCTION__ = "fe_op_add" >>>> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >>>> ber =<value optimized out> >>>> last = 0x8b402e71 "" >>>> dn = {bv_len = 38, bv_val = 0x8b402d98 >>>> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >>>> len = 28 >>>> tag =<value optimized out> >>>> modlist = 0x8b4015f0 >>>> modtail = 0x8b403694 >>>> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >>>> sm_nvalues = 0x0, sm_numvals = 2375635128, >>>> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >>>> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >>>> textbuf = >>>> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >>>> >>>> '\000'<repeats 20 times>, >>>> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >>>> >>>> rc =<value optimized out> >>>> freevals =<value optimized out> >>>> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >>>> oe_db = 0x0} >>>> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >>>> at connection.c:1150 >>>> rc =<value optimized out> >>>> cancel =<value optimized out> >>>> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, 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} >>>> tag = 104 >>>> opidx = SLAP_OP_ADD >>>> conn = 0xb7f3bc10 >>>> memctx = 0xa372570 >>>> memctx_null = 0x0 >>>> __PRETTY_FUNCTION__ = "connection_operation" >>>> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >>>> connection.c:1286 >>>> s =<value optimized out> >>>> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >>>> tpool.c:688 >>>> task = 0xa382e10 >>>> work_list =<value optimized out> >>>> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >>>> ltk_data = 0xa372570, >>>> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >>>> 0xa363398, ltk_data = 0xa371a88, >>>> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >>>> 0x8078320, ltk_data = 0xa37de68, >>>> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >>>> 0x808dde0, ltk_data = 0x0, >>>> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >>>> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >>>> kctx =<value optimized out> >>>> keyslot = 241 >>>> hash = 5278961 >>>> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >>>> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >>>> No symbol table info available. >>>> #15 0x002f746e in clone () from /lib/libc.so.6 >>>> No symbol table info available. >>>> >>>> >>>> >>>> >>>> >>> >>> > -- David Coutadeur - intégrateur LinID Groupe LINAGORA - BU LGS +33 1 46 96 63 63 / poste 601 80 rue Roque de Fillol 92800 PUTEAUX "/La présente transmission contient des informations confidentielles appartenant à Linagora, exclusivement destinées au(x) destinataire(s) identifié(s) ci-dessus. Si vous n'en faites pas partie, toute reproduction, distribution ou divulgation de tout ou partie des informations de cette transmission, ou toute action effectuée sur la base de celles-ci vous sont formellement interdites. Si vous avez reçu cette transmission par erreur, nous vous remercions de nous en avertir et de la détruire de votre système d'information. The present transmission contains privileged and confidential information belonging to Linagora, exclusively intended for the recipient(s) thereabove identified. If you are not one of these aforementioned recipients, any reproduction, distribution, disclosure of said information in whole or in part, as well as any action undertaken on the basis of said information are strictly prohibited. If you received the present transmission by mistake, please inform us and destroy it from your messenging and information systems./"

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jul '12

12 Jul '12

On 06/18/2012 01:55 PM, hyc(a)symas.com wrote: > Jan Synacek wrote: >> On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >>> jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: git (c73ec15) >>>> OS: linux-fedora17 >>>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> >>>> I'm using a 2-node mmr setup on my local machine - configuration files and >>>> 'uploader' scripts are provided in the archive. >>>> >>>> 1) I have the two nodes running. >>>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>>> slapd's memory usage. >>>> 3) After some time (at about 2k users on my system), slapd consumes a large >>>> amount of memory which is still growing >>>> >>>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>>> using it e.g. for modifying each user's email, does NOT result in any memory >>>> leakage. >>>> >>>> I have also created a massif output using valgrind's massif tool: >>>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>>> >>>> I found a very similar bug (#7292), but I'm not sure if it's related. >>> >>> Running RE24 with valgrind --leak-check=full I see no leak when running your >>> test. That should be the same as git c73ec15. No idea what leak you're seeing. >>> >> >> The memory consumption still grows and slapd eventually gets killed by oom-killer. > > Perhaps you're seeing fragmentation in the glibc malloc library. Please test > RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire > test with both valgrind and with tcmalloc's heap checker and neither one shows > any leak. > I've done more tests and have some additional observations to add: * tcmalloc doesn't make any difference * if syncing finishes, memory usage drops considerably * putting sleep between ldapadd and ldapmodify in the script seems to stop the memory consumption * also, generating one big ldif, that is used modify all the users in groupOfNames just once (calling ldapmodify only once that is, not calling it once for every user), seems to help as well; the ldif is formatted like so: dn: cn=users,dc=yes,dc=my changetype:modify add: member member: uid=test-1(a)yes1.my,dc=yes,dc=my - add: member member: uid=test-2(a)yes1.my,dc=yes,dc=my - ... I'm also including my configure setup: export CFLAGS="$(rpm --eval %{optflags}) -O2 -fPIC -D_REENTRANT -DHAVE_TLS -DHAVE_MOZNSS" export LIBS="-lpthread -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4" CFLAGS="${CFLAGS:--g -pipe -Wall }"; export CFLAGS; CXXFLAGS="${CXXFLAGS:--g -pipe -Wall }"; export CXXFLAGS; FFLAGS="${FFLAGS:--g -pipe -Wall }"; export FFLAGS; ./configure \ --with-threads=posix --disable-static --with-tls=no \ --with-pic --with-cyrus-sasl \ --enable-bdb \ --enable-overlays --enable-slapd --enable-spasswd --enable-modules --enable-slapi \ --enable-accesslog \ --enable-wrappers -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2012