openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#7952) [LMDB] Add mdb_load and mdb_dump to .gitignore
by hyc＠symas.com 02 Oct '14

02 Oct '14

jcd(a)tribudubois.net wrote: > Full_Name: Jean-Christophe Dubois > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.235.240.156) > > > mdb_load and mdb_dump are 2 binaries that are generated as part of the lmdb > build. > > They should be added to the .gitignore file. Fixed in mdb.master > > Patch available at URL below: > > https://github.com/jcdubois/lmdb/commit/f8367c5ff8dd98c14fece6068ec516ee8db… > > JC > > > > > -- -- 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#7954) [LMDB] fix uninitialize struct member.
by jcd＠tribudubois.net 02 Oct '14

02 Oct '14

Full_Name: Jean-Christophe Dubois Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.235.240.156) In the mdb_env_cwalk() function the mc_flags member of the "mc" MDB_cursor instance is not initialized. But in the mdb_page_search_root() called a bit later (line 8407) this flag will be updated from this uninitialized value. The mc_flags member needs to be initialized to a known value. Patch available at URL below: https://github.com/jcdubois/lmdb/commit/57d0d380a18957245c8a011e73564909966… JC

1 0

(ITS#7953) [LMDB] Add *.lo to .gitignore
by jcd＠tribudubois.net 02 Oct '14

02 Oct '14

Full_Name: Jean-Christophe Dubois Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.235.240.156) lmdb build is generating several binary .lo files. They should be added to the .gitignore file. Patch available at URL below: https://github.com/jcdubois/lmdb/commit/fd1903136e7549dd349bafc4de633c616ef… JC

1 0

(ITS#7952) [LMDB] Add mdb_load and mdb_dump to .gitignore
by jcd＠tribudubois.net 02 Oct '14

02 Oct '14

Full_Name: Jean-Christophe Dubois Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.235.240.156) mdb_load and mdb_dump are 2 binaries that are generated as part of the lmdb build. They should be added to the .gitignore file. Patch available at URL below: https://github.com/jcdubois/lmdb/commit/f8367c5ff8dd98c14fece6068ec516ee8db… JC

1 0

Re: (ITS#7951) slapd deadlocks during mod operation
by hyc＠symas.com 26 Sep '14

26 Sep '14

christianclinton(a)gmail.com wrote: > Full_Name: Christian Clinton > Version: 2.4.36 > OS: CentOS 6.4 > URL: ftp://ftp.openldap.org/incoming/christian-clinton-140925.zip > Submission from: (NULL) (216.148.0.72) > > > Description: Slapd hangs during LDAP modification operation. Subsequent read or > write operations hang from all clients until slapd restart. 2.4.36 is over a year old. Bugs reported against old releases will not be investigated. > slapd logs show: > slapd[11213]: => bdb_idl_insert_key: c_put id failed: BDB0068 DB_LOCK_DEADLOCK: > Locker killed to resolve a deadlock (-30993) > slapd[11213]: conn=12787 op=25: attribute "entryCSN" index add failure > slapd[11213]: => bdb_idl_insert_key: c_put id failed: BDB0068 DB_LOCK_DEADLOCK: > Locker killed to resolve a deadlock (-30993) > slapd[11213]: conn=13382 op=3: attribute "entryCSN" index add failure This is a normal occurrence in BerkeleyDB and does not indicate an actual error. The bdb/hdb backend code automatically retries when a BDB deadlock is reported. > This issue has occurred sporadically for several months across different > OpenLDAP versions. I managed to capture of a backtrace for two occurrences of > the crash (excerpt below, full backtrace loloaded to FTP). In both instances, a > couple of threads were acquiring locks which is where I suspect the issue lies. > > BT: ftp://ftp.openldap.org/incoming/christian-clinton-140925.zip When talking about BDB deadlock issues you should always obtain the output from db_stat -CA on the db directory, in addition to the full stack trace. You should consider testing with different BDB versions as well, as issues are known to slip into various updates. > Environment: > OS: CentOS 6.4 > OpenLDAP 2.4.36 > 1 Master w/ many syncrepl slaves > > Thread 129 (Thread 0x7f10ddffb700 (LWP 16586)): > #0 0x00000037e560b43c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f11a076e623 in __db_hybrid_mutex_suspend () from > /usr/local/openldap/lib/libdb-5.3.so > #2 0x00007f11a076d6eb in __db_tas_mutex_lock () from > /usr/local/openldap/lib/libdb-5.3.so > #3 0x00007f11a08205e6 in __lock_get_internal () from > /usr/local/openldap/lib/libdb-5.3.so > #4 0x00007f11a08208ab in __lock_get () from > /usr/local/openldap/lib/libdb-5.3.so > #5 0x00007f11a0848468 in __db_lget () from > /usr/local/openldap/lib/libdb-5.3.so > #6 0x00007f11a078dff6 in __bam_search () from > /usr/local/openldap/lib/libdb-5.3.so > #7 0x00007f11a0778ed6 in __bamc_search () from > /usr/local/openldap/lib/libdb-5.3.so > #8 0x00007f11a077c637 in __bamc_get () from > /usr/local/openldap/lib/libdb-5.3.so > #9 0x00007f11a083507d in __dbc_iget () from > /usr/local/openldap/lib/libdb-5.3.so > #10 0x00007f11a0845d00 in __dbc_get_pp () from > /usr/local/openldap/lib/libdb-5.3.so > #11 0x00000000005489ed in hdb_idl_delete_key (be=0x7f10ddff9480, > db=0x7f111a3f9610, tid=0x7f10603015b0, key=0x7f10ddff8ec0, id=250418) at > idl.c:947 > #12 0x000000000054b455 in hdb_key_change (be=0x7f10ddff9480, db=0x7f111a3f9610, > txn=0x7f10603015b0, k=0x7f1060001ab0, id=250418, op=2) at key.c:97 > #13 0x000000000054a4ee in indexer (op=0x7f10603c9f90, txn=0x7f10603015b0, > ad=0x1b6d5e0, atname=0x1b6d4b8, vals=0x7f1060001a88, id=250418, opid=2, mask=4) > at index.c:214 > #14 0x000000000054a978 in index_at_values (op=0x7f10603c9f90, > txn=0x7f10603015b0, ad=0x1b6d5e0, type=0x1b6d450, tags=0x1b6d600, > vals=0x7f1060001a88, id=250418, opid=2) > at index.c:337 > #15 0x000000000054aaf6 in hdb_index_values (op=0x7f10603c9f90, > txn=0x7f10603015b0, desc=0x1b6d5e0, vals=0x7f1060001a88, id=250418, opid=2) at > index.c:386 > #16 0x00000000004dbb44 in hdb_modify_internal (op=0x7f10603c9f90, > tid=0x7f10603015b0, modlist=0x7f10603f9930, e=0x7f10ddff91d0, > text=0x7f10ddffa990, > textbuf=0x7f10ddff9260 "\300\032\070\220\020\177", textlen=256) at > modify.c:358 > #17 0x00000000004dcc09 in hdb_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at > modify.c:642 > #18 0x00000000004bbc11 in overlay_op_walk (op=0x7f10603c9f90, rs=0x7f10ddffa970, > which=op_modify, oi=0x1c9a500, on=0x0) at backover.c:671 > #19 0x00000000004bbe28 in over_op_func (op=0x7f10603c9f90, rs=0x7f10ddffa970, > which=op_modify) at backover.c:723 > #20 0x00000000004bbf64 in over_op_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) > at backover.c:762 > #21 0x000000000044d5c6 in fe_op_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at > modify.c:303 > #22 0x000000000044ce98 in do_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at > modify.c:177 > #23 0x000000000042d068 in connection_operation (ctx=0x7f10ddffaaa0, > arg_v=0x7f10603c9f90) at connection.c:1155 > #24 0x000000000042d609 in connection_read_thread (ctx=0x7f10ddffaaa0, argv=0xb7) > at connection.c:1291 > #25 0x0000000000596261 in ldap_int_thread_pool_wrapper (xpool=0x1b77350) at > tpool.c:688 > #26 0x00000037e5607851 in start_thread () from /lib64/libpthread.so.0 > #27 0x00000037e52e890d in clone () from /lib64/libc.so.6 > > Thread 71 (Thread 0x7f0fedffb700 (LWP 16648)): > #0 0x00000037e560b43c in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f11a076e623 in __db_hybrid_mutex_suspend () from > /usr/local/openldap/lib/libdb-5.3.so > #2 0x00007f11a076d6eb in __db_tas_mutex_lock () from > /usr/local/openldap/lib/libdb-5.3.so > #3 0x00007f11a08205e6 in __lock_get_internal () from > /usr/local/openldap/lib/libdb-5.3.so > #4 0x00007f11a08208ab in __lock_get () from > /usr/local/openldap/lib/libdb-5.3.so > #5 0x00007f11a0848468 in __db_lget () from > /usr/local/openldap/lib/libdb-5.3.so > #6 0x00007f11a078dff6 in __bam_search () from > /usr/local/openldap/lib/libdb-5.3.so > #7 0x00007f11a0778ed6 in __bamc_search () from > /usr/local/openldap/lib/libdb-5.3.so > #8 0x00007f11a077cb1f in __bamc_get () from > /usr/local/openldap/lib/libdb-5.3.so > #9 0x00007f11a083507d in __dbc_iget () from > /usr/local/openldap/lib/libdb-5.3.so > #10 0x00007f11a0845d00 in __dbc_get_pp () from > /usr/local/openldap/lib/libdb-5.3.so > #11 0x000000000053f414 in hdb_dn2id_delete (op=0x7f10883ba740, > txn=0x7f10a82e7430, eip=0x7f10505a82b0, e=0x7f117b58b968) at dn2id.c:646 > #12 0x000000000053d8f0 in hdb_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at > dele.c.c:406 > #13 0x00000000004bbc11 in overlay_op_walk (op=0x7f10883ba740, rs=0x7f0fedffa970, > which=op_delete, oi=0x1c9a500, on=0x0) at backover.c:671 > #14 0x00000000004bbe28 in over_op_func (op=0x7f10883ba740, rs=0x7f0fedffa970, > which=op_delete) at backover.c:723 > #15 0x00000000004bbfe2 in over_op_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) > at backover.c:780 > #16 0x000000000044ff7c in fe_op_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at > delete.c:174 > #17 0x000000000044fbef in do_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at > delete.c:95 > #18 0x000000000042d068 in connection_operation (ctx=0x7f0fedffaaa0, > arg_v=0x7f10883ba740) at connection.c:1155 > #19 0x000000000042d609 in connection_read_thread (ctx=0x7f0fedffaaa0, argv=0x3f) > at connection.cA1A1291 > #20 0x0000000000596261 in ldap_int_thread_pool_wrapper (xpool=0x1b77350) at > tpool.c:688 > #21 0x00000037e5607851 in start_thread () from /lib64/libpthread.so.0 > #22 0x00000037e52e890d in clone () from /lib64/libc.so.6 > > -- -- 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#7951) slapd deadlocks during mod operation
by quanah＠zimbra.com 26 Sep '14

26 Sep '14

--On Friday, September 26, 2014 1:39 AM +0000 christianclinton(a)gmail.com wrote: > Full_Name: Christian Clinton > Version: 2.4.36 > OS: CentOS 6.4 > URL: ftp://ftp.openldap.org/incoming/christian-clinton-140925.zip > Submission from: (NULL) (216.148.0.72) > > > Description: Slapd hangs during LDAP modification operation. Subsequent > read or write operations hang from all clients until slapd restart. Upgrade to OpenLDAP 2.4.40, use back-mdb with a 64-bit OS, and dump the deprecated and useless back-hdb/bdb. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7951) slapd deadlocks during mod operation
by christianclinton＠gmail.com 26 Sep '14

26 Sep '14

Full_Name: Christian Clinton Version: 2.4.36 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/christian-clinton-140925.zip Submission from: (NULL) (216.148.0.72) Description: Slapd hangs during LDAP modification operation. Subsequent read or write operations hang from all clients until slapd restart. slapd logs show: slapd[11213]: => bdb_idl_insert_key: c_put id failed: BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30993) slapd[11213]: conn=12787 op=25: attribute "entryCSN" index add failure slapd[11213]: => bdb_idl_insert_key: c_put id failed: BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30993) slapd[11213]: conn=13382 op=3: attribute "entryCSN" index add failure This issue has occurred sporadically for several months across different OpenLDAP versions. I managed to capture of a backtrace for two occurrences of the crash (excerpt below, full backtrace loloaded to FTP). In both instances, a couple of threads were acquiring locks which is where I suspect the issue lies. BT: ftp://ftp.openldap.org/incoming/christian-clinton-140925.zip Environment: OS: CentOS 6.4 OpenLDAP 2.4.36 1 Master w/ many syncrepl slaves Thread 129 (Thread 0x7f10ddffb700 (LWP 16586)): #0 0x00000037e560b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f11a076e623 in __db_hybrid_mutex_suspend () from /usr/local/openldap/lib/libdb-5.3.so #2 0x00007f11a076d6eb in __db_tas_mutex_lock () from /usr/local/openldap/lib/libdb-5.3.so #3 0x00007f11a08205e6 in __lock_get_internal () from /usr/local/openldap/lib/libdb-5.3.so #4 0x00007f11a08208ab in __lock_get () from /usr/local/openldap/lib/libdb-5.3.so #5 0x00007f11a0848468 in __db_lget () from /usr/local/openldap/lib/libdb-5.3.so #6 0x00007f11a078dff6 in __bam_search () from /usr/local/openldap/lib/libdb-5.3.so #7 0x00007f11a0778ed6 in __bamc_search () from /usr/local/openldap/lib/libdb-5.3.so #8 0x00007f11a077c637 in __bamc_get () from /usr/local/openldap/lib/libdb-5.3.so #9 0x00007f11a083507d in __dbc_iget () from /usr/local/openldap/lib/libdb-5.3.so #10 0x00007f11a0845d00 in __dbc_get_pp () from /usr/local/openldap/lib/libdb-5.3.so #11 0x00000000005489ed in hdb_idl_delete_key (be=0x7f10ddff9480, db=0x7f111a3f9610, tid=0x7f10603015b0, key=0x7f10ddff8ec0, id=250418) at idl.c:947 #12 0x000000000054b455 in hdb_key_change (be=0x7f10ddff9480, db=0x7f111a3f9610, txn=0x7f10603015b0, k=0x7f1060001ab0, id=250418, op=2) at key.c:97 #13 0x000000000054a4ee in indexer (op=0x7f10603c9f90, txn=0x7f10603015b0, ad=0x1b6d5e0, atname=0x1b6d4b8, vals=0x7f1060001a88, id=250418, opid=2, mask=4) at index.c:214 #14 0x000000000054a978 in index_at_values (op=0x7f10603c9f90, txn=0x7f10603015b0, ad=0x1b6d5e0, type=0x1b6d450, tags=0x1b6d600, vals=0x7f1060001a88, id=250418, opid=2) at index.c:337 #15 0x000000000054aaf6 in hdb_index_values (op=0x7f10603c9f90, txn=0x7f10603015b0, desc=0x1b6d5e0, vals=0x7f1060001a88, id=250418, opid=2) at index.c:386 #16 0x00000000004dbb44 in hdb_modify_internal (op=0x7f10603c9f90, tid=0x7f10603015b0, modlist=0x7f10603f9930, e=0x7f10ddff91d0, text=0x7f10ddffa990, textbuf=0x7f10ddff9260 "\300\032\070\220\020\177", textlen=256) at modify.c:358 #17 0x00000000004dcc09 in hdb_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at modify.c:642 #18 0x00000000004bbc11 in overlay_op_walk (op=0x7f10603c9f90, rs=0x7f10ddffa970, which=op_modify, oi=0x1c9a500, on=0x0) at backover.c:671 #19 0x00000000004bbe28 in over_op_func (op=0x7f10603c9f90, rs=0x7f10ddffa970, which=op_modify) at backover.c:723 #20 0x00000000004bbf64 in over_op_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at backover.c:762 #21 0x000000000044d5c6 in fe_op_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at modify.c:303 #22 0x000000000044ce98 in do_modify (op=0x7f10603c9f90, rs=0x7f10ddffa970) at modify.c:177 #23 0x000000000042d068 in connection_operation (ctx=0x7f10ddffaaa0, arg_v=0x7f10603c9f90) at connection.c:1155 #24 0x000000000042d609 in connection_read_thread (ctx=0x7f10ddffaaa0, argv=0xb7) at connection.c:1291 #25 0x0000000000596261 in ldap_int_thread_pool_wrapper (xpool=0x1b77350) at tpool.c:688 #26 0x00000037e5607851 in start_thread () from /lib64/libpthread.so.0 #27 0x00000037e52e890d in clone () from /lib64/libc.so.6 Thread 71 (Thread 0x7f0fedffb700 (LWP 16648)): #0 0x00000037e560b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f11a076e623 in __db_hybrid_mutex_suspend () from /usr/local/openldap/lib/libdb-5.3.so #2 0x00007f11a076d6eb in __db_tas_mutex_lock () from /usr/local/openldap/lib/libdb-5.3.so #3 0x00007f11a08205e6 in __lock_get_internal () from /usr/local/openldap/lib/libdb-5.3.so #4 0x00007f11a08208ab in __lock_get () from /usr/local/openldap/lib/libdb-5.3.so #5 0x00007f11a0848468 in __db_lget () from /usr/local/openldap/lib/libdb-5.3.so #6 0x00007f11a078dff6 in __bam_search () from /usr/local/openldap/lib/libdb-5.3.so #7 0x00007f11a0778ed6 in __bamc_search () from /usr/local/openldap/lib/libdb-5.3.so #8 0x00007f11a077cb1f in __bamc_get () from /usr/local/openldap/lib/libdb-5.3.so #9 0x00007f11a083507d in __dbc_iget () from /usr/local/openldap/lib/libdb-5.3.so #10 0x00007f11a0845d00 in __dbc_get_pp () from /usr/local/openldap/lib/libdb-5.3.so #11 0x000000000053f414 in hdb_dn2id_delete (op=0x7f10883ba740, txn=0x7f10a82e7430, eip=0x7f10505a82b0, e=0x7f117b58b968) at dn2id.c:646 #12 0x000000000053d8f0 in hdb_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at dele.c.c:406 #13 0x00000000004bbc11 in overlay_op_walk (op=0x7f10883ba740, rs=0x7f0fedffa970, which=op_delete, oi=0x1c9a500, on=0x0) at backover.c:671 #14 0x00000000004bbe28 in over_op_func (op=0x7f10883ba740, rs=0x7f0fedffa970, which=op_delete) at backover.c:723 #15 0x00000000004bbfe2 in over_op_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at backover.c:780 #16 0x000000000044ff7c in fe_op_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at delete.c:174 #17 0x000000000044fbef in do_delete (op=0x7f10883ba740, rs=0x7f0fedffa970) at delete.c:95 #18 0x000000000042d068 in connection_operation (ctx=0x7f0fedffaaa0, arg_v=0x7f10883ba740) at connection.c:1155 #19 0x000000000042d609 in connection_read_thread (ctx=0x7f0fedffaaa0, argv=0x3f) at connection.cA1A1291 #20 0x0000000000596261 in ldap_int_thread_pool_wrapper (xpool=0x1b77350) at tpool.c:688 #21 0x00000037e5607851 in start_thread () from /lib64/libpthread.so.0 #22 0x00000037e52e890d in clone () from /lib64/libc.so.6

1 0

Re: (ITS#7950) Memory leak issue
by michael＠stroeder.com 25 Sep '14

25 Sep '14

This is a cryptographically signed message in MIME format. --------------ms090903050807020603070801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable kuldeep.itbhu(a)gmail.com wrote: > I am getting memory leak when calling below openldap api. > I am using openldap-2.3.31 version. Why don't you use a recent OpenLDAP version? 2.3.x has status historic for years and thus is not maintained anymore. Ciao, Michael. --------------ms090903050807020603070801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDA5MjUxMDQ0MjZaMCMGCSqGSIb3DQEJBDEWBBTf/Fm/SzrM 3B3fU7Fjsow2Kvfv0zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAvAgHa4z6 bBIzh6FOgOml/hDa1iBawJXwNCTj8XkE6BLg7gUu65j9Sf3wsZOgTiEGjXcbD1Lrh2xqb3GJ vsq1Y1pbo5vixqghtvOElOhLpff6/pVExo8KzIUwknLhRo4mnsMn8MUAyE0Si5nCPj3AUWWX ZukBXWktDlLYhEQ6N2j6/nJZ2ajrbhTW5tDQACCy11i91jYR+aMPxDmeA1l05q1qGMWICUmL Cti/GpwTrbodJnSO373hwxTCugEs2VQlOauARGMlKm09e0u1rlalz+NyTIyKCdfkWIkhLtnO E17IdIe7smjt4dnoRXDi/Os+zuyV/5ax1hRM51miUXQ+SAAAAAAAAA== --------------ms090903050807020603070801--

1 0

(ITS#7950) Memory leak issue
by kuldeep.itbhu＠gmail.com 25 Sep '14

25 Sep '14

Full_Name: Kuldeep Khare Version: 2.3.31 OS: Qnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.247.254.226) Hi, I am getting memory leak when calling below openldap api. I am using openldap-2.3.31 version. if(ldap_init()) { ldap_configure_client(mSession,clientip); int ldap_version = 3; ldap_set_option(mSession, LDAP_OPT_REFERRALS, LDAP_OPT_OFF); ldap_set_option(mSession, LDAP_OPT_PROTOCOL_VERSION, &ldap_version); // set timeout for every complete search ldap_set_option(mSession, LDAP_OPT_TIMELIMIT, &SMA_CERT_LDAP_SEARCH_TIMEOUT); // set timeout for any api call struct timeval api_timeout; api_timeout.tv_sec = SMA_CERT_LDAP_API_TIMEOUT; api_timeout.tv_usec = 0; struct timeval net_timeout; net_timeout.tv_sec = SMA_CERT_LDAP_NET_TIMEOUT; net_timeout.tv_usec = 0; ldap_set_option(mSession, LDAP_OPT_TIMEOUT, &api_timeout); ldap_set_option(mSession, LDAP_OPT_NETWORK_TIMEOUT, &net_timeout); } ldap_simple_bind(); //Only if init is successful ldap_result(); //only if init is successful ldap_unbind(); If anyone has encountered this issue please help. Thanks, Kuldeep

1 0

Re: (ITS#7949) Slapd deadlocks on connection
by quanah＠zimbra.com 24 Sep '14

24 Sep '14

--On Wednesday, September 24, 2014 10:39 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.40 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.64.214) > Never mind, due to a code change that affected a feature backport I have privately. Closing this ITS. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

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