Re: (ITS#7951) slapd deadlocks during mod operation
by hyc＠symas.com
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/
8 years, 8 months
Re: (ITS#7951) slapd deadlocks during mod operation
by quanah＠zimbra.com
--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
8 years, 8 months
(ITS#7951) slapd deadlocks during mod operation
by christianclinton＠gmail.com
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
8 years, 8 months
Re: (ITS#7950) Memory leak issue
by michael＠stroeder.com
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--
8 years, 8 months
(ITS#7950) Memory leak issue
by kuldeep.itbhu＠gmail.com
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
8 years, 8 months
Re: (ITS#7949) Slapd deadlocks on connection
by quanah＠zimbra.com
--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
8 years, 8 months
(ITS#7949) Slapd deadlocks on connection
by quanah＠openldap.org
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)
After deploying OpenLDAP 2.4.40, slapd becomes completely unresponsive, and
every thread but the daemon is deadlocked
Thread 10 (Thread 0x7fc4c7ba2700 (LWP 14910)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64%lolowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043da27 in connection_write (s=10) at connection.c:1917
#6 0x000000000043804b in slapd_daemon_task (ptr=0x2749d38) at daemon.c:2757
#7 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c7ba2700) at
pthread_create.c:308
#8 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9 0x0000000000000000 in ?? ()
Thread 9 (Thread 0x7fc4c73a1700 (LWP 14914)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1 0x00007fd8ce078745 in ldap_pvt_thread_cond_wait (cond=0x302bd38,
mutex=0x302bd10) at thr_posix.c:277
#2 0x0000000000451459 in send_ldap_ber (op=0x2c483c0, ber=0x7fc4c739f800) at
result.c:377
#3 0x00000000004550ca in slap_send_search_entry (op=0x2c483c0,
rs=0x7fc4c73a0a00) at result.c:1433
#4 0x000000000043f4ad in fe_op_search (op=0x2c483c0, rs=0x7fc4c73a0a00) at
search.c:327
#5 0x000000000043f0c1 in do_search (op=0x2c483c0, rs=0x7fc4c73a0a00) at
search.c:247
#6 0x000000000043b937 in connection_operation (ctx=0x7fc4c73a0b40,
arg_v=0x2c483c0) at connection.c:1132
#7 0x000000000043bec9 in connection_read_thread (ctx=0x7fc4c73a0b40, argv=0xa)
at connection.c:1268
#8 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#9 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c73a1700) at
pthread_create.c:308
#10 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 8 (Thread 0x7fc4c6ba0700 (LWP 14915)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c6b9faf0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c6b9fb40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c6ba0700) at
pthread_create.c:308
#9 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
ATAThread 7 (Thread 0x7fc4c639f700 (LWP 14916)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c639eaf0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c639eb40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c639f700) at
pthread_create.c:308
#9 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
Thread 6 (Thread 0x7fc4c5b9e700 (LWP 22253)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c5b9daf0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c5b9db40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c5b9e700) at
pthread_create.c:308
#9 0x00007fd8cc16b3finin clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
Thread 5 (Thread 0x7fc4c539d700 (LWP 22254)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
3231 0x000078c8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c539caf0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c539cb40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c539d700) at
pthread_create.c:308
#9 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
Thread 4 (Thread 0x7fc4c4b9c700 (LWP 22255)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1 0x00007fd8ce078745 in ldap_pvt_thread_cond_wait (cond=0x302bce0,
mutex=0x302bcb8) at thr_posix.c:277
#2 0x000000000043ab12 in connection_wake_writers (c=0x302bb80) at
connection.c:765
#3 0x000000000043acb2 in connection_closing (c=0x302bb80, why=0x0) at
connection.c:800
#4 0x000000000043bbff in connection_operation (ctx=0x7fc4c4b9bb40,
arg_v=0x86b6940) at connection.c:1182
#5 0x000000000043bec9 in connection_read_thread (ctx=0x7fc4c4b9bb40, argv=0xa)
at connection.c:1268
#6 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#7 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c4b9c700) at
pthread_create.c:308
#8 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7fc4c439b700 (LWP 22256)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c439aaf0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c439ab40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c439b700) at
pthread_create.c:308
#9 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fc4c3b9a700 (LWP 22257)):
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007fd8cc441065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at
pthread_mutex_lock.c:61
#3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at
thr_posix.c:296
#4 0x0000000000439470 in connection_get (s=10) at connection.c:278
#5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c3b99af0) at
connection.c:1310
#6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c3b99b40, argv=0xa)
at connection.c:1261
#7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at
tpool.c:945
#8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c3b9a700) at
pthread_create.c:308
#9 0x00007fd8cc16b3fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fd8ce727740 (LWP 14909)):
#0 0x00007fd8cc440148 in pthread_join (threadid=140483141183232,
thread_return=0x0) at pthread_join.c:89
#1 0x00007fd8ce078686 in ldap_pvt_thread_join (thread=140483141183232,
thread_return=0x0) at thr_posix.c:197
#2 0x000000000043893a in slapd_daemon () at daemon.c:2907
#3 0x0000000000414b38 in main (argc=9, argv=0x7fff5361c928) at main.c:1012
(gdb)
8 years, 8 months
(ITS#7948) mdb_copy insecure permissions
by geert＠hendrickx.be
Full_Name: Geert Hendrickx
Version: 2.4.39
OS: centos6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.123.14.2)
mdb_copy creates a copy using the default umask. This usually leads to insecure
(world readable) copies, as typically an LDAP databse is 600 owned by some
unprivileged ldap user.
I suggest to copy the behaviour of cp, scp, rsync etc: preserve mode by default,
preserve all metadata (uid:gid, mode, mtime, atime ...) when invoked with -p ?
8 years, 8 months
Re: (ITS#7947) version skew? mdb_load: line 6: unrecognized keyword ignored: db_pagesize
by hyc＠symas.com
j.e.aten(a)gmail.com wrote:
> Full_Name: Jason Aten
> Version: LMDB 0.9.14
> OS: ubuntu 12.04 / amd64
> URL:
> Submission from: (NULL) (2001:4807:2:104:d959:722c:ad90:ee70)
>
>
>
> There may have been version skew, because the mdb_load command does not
> understand the output of the mdb_dump command. See the following error in the
> context below.
Works as designed. This message is not an error, otherwise the situation would
not be "ignored."
> "mdb_load: line 6: unrecognized keyword ignored: db_pagesize"
The mdb_dump format is a copy of BDB's db_dump format, which needs the
db_pagesize.
Closing this ITS.
>
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat
> var/lmdb_data
> Status of Main DB
> Tree depth: 1
> Branch pages: 0
> Leaf pages: 1
> Overflow pages: 0
> Entries: 1
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat -V
> var/lmdb_data
> LMDB 0.9.14: (September 15, 2014)
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ which
> mdb_stat
> /usr/local/bin/mdb_stat
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ ls -al `which
> mdb_stat`
> -rwxr-xr-x 1 root root 275324 Sep 18 03:17 /usr/local/bin/mdb_stat
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
> var/lmdb_data/
> VERSION=3
> format=bytevalue
> type=btree
> mapsize=20971520
> maxreaders=126Ûdb_pagesize=4096
> HEADER=END
> 00016d796b6579
> 6a61736f6e207761732068657265
> DATA=END
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
> var/lmdb_data/ | mdb_load
> usage: mdb_load dbpath [-V] [-f input] [-n] [-s name] [-N] [-T]
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
> var/lmdb_data/ | mdb_load var/lmdb_data
> mdb_load: line 6: unrecognized keyword ignored: db_pagesize
> jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 8 months
(ITS#7947) version skew? mdb_load: line 6: unrecognized keyword ignored: db_pagesize
by j.e.aten＠gmail.com
Full_Name: Jason Aten
Version: LMDB 0.9.14
OS: ubuntu 12.04 / amd64
URL:
Submission from: (NULL) (2001:4807:2:104:d959:722c:ad90:ee70)
There may have been version skew, because the mdb_load command does not
understand the output of the mdb_dump command. See the following error in the
context below.
"mdb_load: line 6: unrecognized keyword ignored: db_pagesize"
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat
var/lmdb_data
Status of Main DB
Tree depth: 1
Branch pages: 0
Leaf pages: 1
Overflow pages: 0
Entries: 1
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat -V
var/lmdb_data
LMDB 0.9.14: (September 15, 2014)
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ which
mdb_stat
/usr/local/bin/mdb_stat
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ ls -al `which
mdb_stat`
-rwxr-xr-x 1 root root 275324 Sep 18 03:17 /usr/local/bin/mdb_stat
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
var/lmdb_data/
VERSION=3
format=bytevalue
type=btree
mapsize=20971520
maxreaders=126Ûdb_pagesize=4096
HEADER=END
00016d796b6579
6a61736f6e207761732068657265
DATA=END
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
var/lmdb_data/ | mdb_load
usage: mdb_load dbpath [-V] [-f input] [-n] [-s name] [-N] [-T]
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump
var/lmdb_data/ | mdb_load var/lmdb_data
mdb_load: line 6: unrecognized keyword ignored: db_pagesize
jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$
8 years, 8 months
