openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#7371) slapd locks up at shutdown in SSL threads
by hyc＠symas.com 27 Aug '12

27 Aug '12

quanah(a)zimbra.com wrote: > --On Monday, August 27, 2012 6:14 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.32 + ITS7356 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.196.25.250) > > In reviewing the logs, slapd actually locked up on startup, not shutdown. Clearly an OpenSSL issue, not an OpenLDAP bug. This ITS should be closed and the issue reported to the OpenSSL project. -- -- 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#7371) slapd locks up at shutdown in SSL threads
by quanah＠zimbra.com 27 Aug '12

27 Aug '12

--On Monday, August 27, 2012 6:14 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 + ITS7356 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) In reviewing the logs, slapd actually locked up on startup, not shutdown. --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

(ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠OpenLDAP.org 27 Aug '12

27 Aug '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 + ITS7356 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) With OpenSSL 1.0.1c (latest). We have twice encountered slapd locking up when being shutdown. Both times, it is locked up in the crypto libraries: #0 0x00007f838666eb53 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00000000004373db in slapd_daemon_task (ptr=0x16cfe48) at daemon.c:2540 #2 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x7f6f80b46700 (LWP 23349)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385683d3b "pmeth_lib.c", line=185) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x3564048, amount=1, type=10, file=0x7f8385683d3b "pmeth_lib.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838560aaed in int_ctx_new (pkey=0x3564040, e=<optimized out>, id=<optimized out>) at pmeth_lib.c:185 #7 0x00007f838560c094 in do_sigver_init (ctx=0x7f6f80b455c0, pctx=0x0, type=0x7f83858d1860, e=0x0, pkey=<optimized out>, ver=<optimized out>) at m_sigver.c:71 #8 0x00007f8385612c90 in ASN1_item_verify (it=0x7f83858cbe40, a=<optimized out>, signature=0x3534e00, asn=0x1f1efc0, pkey=0x3564040) at a_verify.c:185 #9 0x00007f8385632327 in internal_verify (ctx=0x7f6f80b45720) at x509_vfy.c:1627 #10 0x00007f8385632e13 in X509_verify_cert (ctx=0x7f6f80b45720) at x509_vfy.c:367 #11 0x00007f838591474b in ssl3_output_cert_chain (s=0x1dc9180, x=<optimized out>) at s3_both.c:377 #12 0x00007f8385907965 in ssl3_send_server_certificate (s=0x1dc9180) at s3_srvr.c:3336 #13 0x00007f83859090c4 in ssl3_accept (s=0x1dc9180) at s3_srvr.c:415 #14 0x00007f8385915a63 in ssl23_accept (s=0x1dc9180) at s23_srvr.c:210 #15 0x00007f838740e328 in tlso_session_accept (sess=0x1dc9180) at tls_o.c:372 #16 0x00007f838740bb3a in ldap_pvt_tls_accept (sb=0x3530d20, ctx_arg=0x16fa600) at tls2.c:421 #17 0x000000000043bfb5 in connection_read (s=10, cri=0x7f6f80b45b10) at connection.c:1367 #18 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f80b45b60, argv=0xa) at connection.c:1279 #19 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #20 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #21 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #22 0x0000000000000000 in ?? () Thread 8 (Thread 0x7f6f80345700 (LWP 23352)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f838568a7ef "p_lib.c", line=393) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x17bbec8, amount=-1, type=10, file=0x7f838568a7ef "p_lib.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f8385605459 in EVP_PKEY_free (x=0x17bbec0) at p_lib.c:393 #7 0x00007f8385614bfa in X509_PUBKEY_get (key=0x3535b00) at x_pubkey.c:178 #8 0x00007f8385632310 in internal_verify (ctx=0x7f6f80344720) at x509_vfy.c:1620 #9 0x00007f8385632e13 in X509_verify_cert (ctx=0x7f6f80344720) at x509_vfy.c:367 #10 0x00007f838591474b in ssl3_output_cert_chain (s=0x1dc8700, x=<optimized out>) at s3_both.c:377 #11 0x00007f8385907965 in ssl3_send_server_certificate (s=0x1dc8700) at s3_srvr.c:3336 #12 0x00007f83859090c4 in ssl3_accept (s=0x1dc8700) at s3_srvr.c:415 #13 0x00007f8385915a63 in ssl23_accept (s=0x1dc8700) at s23_srvr.c:210 #14 0x00007f838740e328 in tlso_session_accept (sess=0x1dc8700) at tls_o.c:372 #15 0x00007f838740bb3a in ldap_pvt_tls_accept (sb=0x3530c00, ctx_arg=0x16fa600) at tls2.c:421 #16 0x000000000043bfb5 in connection_read (s=12, cri=0x7f6f80344b10) at connection.c:1367 #17 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f80344b60, argv=0xc) at connection.c:1279 #18 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #19 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #20 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x0000000000000000 in ?? () Thread 7 (Thread 0x7f6f7fb44700 (LWP 23455)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3531fb0, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=13, cri=0x7f6f7fb43b10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7fb43b60, argv=0xd) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 6 (Thread 0x7f6f7f343700 (LWP 23458)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568210, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=15, cri=0x7f6f7f342b10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7f342b60, argv=0xf) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 5 (Thread 0x7f6f7eb42700 (LWP 23459)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x35680f0, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=14, cri=0x7f6f7eb41b10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7eb41b60, argv=0xe) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 4 (Thread 0x7f6f7e341700 (LWP 23558)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568330, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=16, cri=0x7f6f7e340b10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7e340b60, argv=0x10) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f6f7db40700 (LWP 23885)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568450, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=17, cri=0x7f6f7db3fb10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7db3fb60, argv=0x11) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f6f7d33f700 (LWP 24326)): #0 0x00007f838694789c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f8386943065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f8386942eba in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at thr_posix.c:296 #4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0 "ssl_cert.c", line=288) at tls_o.c:84 #5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10, file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632 #6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287 #7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314 #8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at tls_o.c:354 #9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at tls2.c:288 #10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568570, ctx_arg=0x16fa600) at tls2.c:410 #11 0x000000000043bfb5 in connection_read (s=18, cri=0x7f6f7d33eb10) at connection.c:1367 #12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7d33eb60, argv=0x12) at connection.c:1279 #13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at tpool.c:688 #14 0x00007f8386940e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #16 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f8387afe740 (LWP 23346)): #0 0x00007f8386942148 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f83873d9c7e in ldap_pvt_thread_join (thread=140116885796608, thread_return=0x0) at thr_posix.c:197 #2 0x0000000000438600 in slapd_daemon () at daemon.c:2930 #3 0x0000000000414968 in main (argc=9, argv=0x7fff01f36168) at main.c:1012

1 0

Re: (ITS#7370) LDAP installation make file error
by quanah＠zimbra.com 27 Aug '12

27 Aug '12

--On Monday, August 27, 2012 2:58 PM +0000 abhishekkalwit(a)gmail.com wrote: > Full_Name: Abhishek Kalwit > Version: openldap-2.4.19 > OS: HP UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.131.68.47) > > > I am trying to install LDAP on HP UX environment 64 bit. > i have successfully installed BerkeleyDB.4.8. > also installed openldap-2.4.19, and ran ./configure successfully. > make depend was also success. > however i am stuck after running make with below error..please help me > resolve. Why are you using OpenLDAP 2.4.19? The current release is OpenLDAP 2.4.32. Also, questions about how to compile the software should be directed to openldap-technical(a)openldap.org. This ITS will be closed. --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

(ITS#7370) LDAP installation make file error
by abhishekkalwit＠gmail.com 27 Aug '12

27 Aug '12

Full_Name: Abhishek Kalwit Version: openldap-2.4.19 OS: HP UX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.131.68.47) I am trying to install LDAP on HP UX environment 64 bit. i have successfully installed BerkeleyDB.4.8. also installed openldap-2.4.19, and ran ./configure successfully. make depend was also success. however i am stuck after running make with below error..please help me resolve. Entering subdirectory liblber /bin/sh ../../libtool --mode=compile cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c -DPIC -o .libs/version.o cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c -o version.o >/dev/null 2>&1 /bin/sh ../../libtool --mode=link cc -g -L/usr/local/lib -L/usr/local/BerkeleyDB.4.8/lib -R/usr/local/BerkeleyDB.4.8/lib -release 2.4 -version-info 7:2:5 -rpath /usr/local/lib -o liblber.la assert.lo decode.lo encode.lo io.lo bprint.lo debug.lo memory.lo options.lo sockbuf.lo stdio.lo version.lo /usr/bin/ld -b +h liblber-2.4.so.7 -o .libs/liblber-2.4.so.7.2 .libs/assert.o .libs/decode.o .libs/encode.o .libs/io.o .libs/bprint.o .libs/debug.o .libs/memory.o .libs/options.o .libs/sockbuf.o .libs/stdio.o .libs/version.o -L/usr/local/BerkeleyDB.4.8/lib -L/usr/local/lib -L/usr/local/BerkeleyDB.4.8/lib -lc ld: Bad machine type: 62 in file .libs/assert.o Fatal error. *** Error exit code 1 Stop. *** Error exit code 1

1 0

Re: (ITS#7368) RE 24 build error: LDAP_BACK_AUTH_DN_AUTHZID’ undeclared etc.
by michael＠stroeder.com 24 Aug '12

24 Aug '12

seems to be fixed by commit a2d1b42e3921d5c874a8f35fcd42047af604ce96

1 0

Re: (ITS#7369) mdb_stat leaves an open transaction if a subdatabase does not exist
by ondrej.kuznik＠acision.com 24 Aug '12

24 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/24/2012 10:55 AM, ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik Version: mdb.master OS: Linux URL: > Submission from: (NULL) (62.168.56.1) > > > If mdb_stat fails (e.g. "mdb_stat db/ this_subdb_does_not_exist"), > it exits immediately rather than abort the txn and close the env. > > When another process has the mdb environment open while this > happens, as long as it does not close it, no new transaction can be > initiated. The whole env then effectively becomes read-only and > unopenable for new processes. A possible patch is at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120824-ITS-7369.patch While I deem this modification too small to be copyrightable, the IPR notice follows just out of caution: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA3RH4ACgkQ9GWxeeH+cXuq0wCfZAR/XoC+5UZTpUvK2c1tK65P iXkAnR0Ad96dNEXL58BJs/ydLHvDmth4 =R+Jc -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7369) mdb_stat leaves an open transaction if a subdatabase does not exist
by ondrej.kuznik＠acision.com 24 Aug '12

24 Aug '12

Full_Name: Ondrej Kuznik Version: mdb.master OS: Linux URL: Submission from: (NULL) (62.168.56.1) If mdb_stat fails (e.g. "mdb_stat db/ this_subdb_does_not_exist"), it exits immediately rather than abort the txn and close the env. When another process has the mdb environment open while this happens, as long as it does not close it, no new transaction can be initiated. The whole env then effectively becomes read-only and unopenable for new processes.

1 0

(ITS#7368) RE 24 build error: LDAP_BACK_AUTH_DN_AUTHZID’ undeclared etc.
by michael＠stroeder.com 23 Aug '12

23 Aug '12

Full_Name: Version: RE24 9f9025a9765940cbdff4316852f1190946e2551d OS: URL: Submission from: (NULL) (79.219.97.190) Probably due to recent patches to back-meta RE24 does not build: make[3]: Entering directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd/back-meta' rm -f version.c ../../../build/mkversion -v "2.4.X" back_meta > version.c /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c init.c mkdir .libs cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c init.c -fPIC -DPIC -o .libs/init.o /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c config.c cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c config.c -fPIC -DPIC -o .libs/config.o config.c: In function ‘meta_back_cf_gen’: config.c:1503:38: error: ‘LDAP_BACK_AUTH_DN_MASK’ undeclared (first use in this function) config.c:1503:38: note: each undeclared identifier is reported only once for each function it appears in config.c:1504:10: error: ‘LDAP_BACK_AUTH_DN_AUTHZID’ undeclared (first use in this function) config.c:1508:10: error: ‘LDAP_BACK_AUTH_DN_WHOAMI’ undeclared (first use in this function) make[3]: *** [config.lo] Error 1 make[3]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd/back-meta' make[2]: *** [back-meta] Error 2 make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by cmikk＠qwest.net 23 Aug '12

23 Aug '12

On Wed, Aug 22, 2012 at 03:23:16PM -0700, Howard Chu wrote: > cmikk(a)qwest.net wrote: > > For example, if you run slapd as an unprivileged user, stop slapd, and do an > > offline slapcat as root, slapd will not start up again as that unprivileged > > user. [snip] > > This sounds like a bug in your platform's sem_open() syscall. If you first > started slapd as an unprivileged user, the semaphore should be owned by that > user. Running slapcat as root should not change the semaphore owner uid, and > the unprivileged owner should still be able to access the semaphore later. In the scenario described, slapd is not running when slapcat starts as root, so slapcat gets an exclusive lock on the lockfile, sem_unlink()s the semaphores created by the unprivileged slapd user, and recreates them, now owned by root. When slapcat finishes, it closes the database and does not remove the semaphores. When slapd starts up, it gets an exclusive lock, attempts to sem_unlink() the semaphores created as (and owned by) root, which fails. In timeline form: 1: slapcat gets exclusive lock on lock.mdb 2: slapcat (as root) unlinks /MDBrXXXX and /MDBwXXXX 3: slapcat (as root) creates /MDBrXXXX and /MDBwXXXX 4: slapcat exits, releasing lock on lock.mdb, leaving behind /MDBrXXXX and /MDBwXXXX (owned by root) 5: slapd gets exclusive lock on lock.mdb 6: slapd (as unpriv) unlinks /MDBrXXXX and /MDBwXXXX. This fails because of the semaphores are owned by root. 7: slapd fails startup. Thanks, -- Chris Mikkelson | "Unfortunately, simplicity is a complicated mess cmikk(a)qwest.net | of a concept." --Taner Edis

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