openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 10 Nov '09

10 Nov '09

--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * mbackes(a)symas.com <mbackes(a)symas.com> [2009-11-10 22:55:10 +0000]: > Hello, Aleksey. >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls = =20 > > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with =20 > > the make install STRIP=3D"" >=20 > Okay. >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. >=20 > > libdb-4.6.so.0 =3D> /usr/local/lib/libdb-4.6.so.0 (0x800a97000) >=20 > At the same time? Your ldd list below shows only berkeley db 4.6. =20 > These don't mix... Not same time. I tried with both backends. Results are same. >=20 > > In slapd config added using hdb as backend and indexes. Testing =20 > > database consist of 1000 users accounts with minimum attributes. On = =20 > > stress test load slapd Segmentation fault in 10-30 sec. >=20 > What sort of operations? Reading (Binds and searches).=20 Test script is loop of id command checking ldap via nss_ldap. >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory = =20 > > address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 >=20 > Does it always fail at the same location? How reproducible is this? Often it is fail in "hdb_idl_fetch_key (be=3DError accessing memory address= ". 100% Reproducible on different hardware. On our normal work, slapd fails every 2-3 hours, on stress test slapd fail in 10-30 sec. Problem on freebsd7.x,8 and openldap2.3.43,2.4.18,2.4.19=20 I tryed on debian lenny and openldap2.4.11 and netbsd5.0.1 and openldap2.4.16 it rock stable. I think problem some where in freebsd and bdb backends.=20 Because freebsd7.1 openldap2.3.43 with depricated ldbm don`t fail on reading.=20 Ask if need any information.=20 Also I can give a shell access to testing server. =20 >=20 > Matthew Backes > Symas Corporation > mbackes(a)symas.com --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJK+lahAAoJELAIdrQw5JcdnyYIAJrpD8OhUgzabzlAfcSmOZhH XUM+vzujX4N/czArACk/dXibX3D2AqQxv1CeUs0pI7Bo+iHLG0gsP6UD8k1fvDEg NecNe1zigD7JEGJDetHTMSXHjYkOvSJsqdBcWjNPuJZn62mg5hVs0S3XdGtqMRxw 4Ck+MwyWiAVQmCDYaXSCEEl6IyGehtD6f5liyNVakHIHG7bZ5MFSm0yP2oMtgxw2 W5vY7nUYK7w3l8ZXqx5pyjQBVBHoUCLFaqHXdXTcBHe3WJ2TQMx6utyvWi3uuqaR HFmg2NMvJSVnTnQsscxZgd2qILAmAx0SE2wd4D312ywsYZvFSGkzjX50JNpklT0= =s9Mn -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--

1 0

ITS#5944 configure options --program-prefix and --program-suffix
by hyc＠symas.com 10 Nov '09

10 Nov '09

The OpenLDAP configure script and Makefiles don't do anything with these options. Sounds like you're looking at a RedHat-specific issue. This ITS will be closed. -- -- 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#6373) syncrepl subentry support
by hyc＠OpenLDAP.org 10 Nov '09

10 Nov '09

Full_Name: Howard Chu Version: 2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc As discussed in this email thread http://www.openldap.org/lists/openldap-software/200910/msg00059.html in some situations it's necessary to store the syncrepl contextCSNs in a subentry of the database, instead of the context entry. Syncrepl in 2.2 used to do this but most of that code was removed in 2.3. It needs to be resurrected and usable as an option.

1 0

Re: (ITS#6312)
by hyc＠symas.com 10 Nov '09

10 Nov '09

neustradamus(a)hotmail.com wrote: > --_add76be3-02e1-47b1-b978-259bce59b479_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > You must change in configure and \include\PORTABLE.H : > > #define vsnprintf _vsnprintf > > with > > #if _MSC_VER < 1500 // 1500 =3D=3D VC++ 9.0 > #define vsnprintf _vsnprintf > #endif > > or > > #if _MSC_VER < 1500 > #define vsnprintf _vsnprintf > #endif You reported this issue against 2.2.16, which is several years obsolete. (Current version is 2.4.19.) The configure script has checked for vsnprintf and _vsnprintf for many years; it will not setup this #define if it doesn't need to. Closing this ITS. -- -- 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#6309) missing SEARCH information
by hyc＠symas.com 10 Nov '09

10 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.18 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I see the following logged at level 256: > > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 ACCEPT from > IP=171.67.219.70:51122 (IP=0.0.0.0:389) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > authcid="service/vacation(a)stanford.edu" authzid="service/vacation(a)stanford.edu" > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > dn="cn=vacation,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI > sasl_ssf=56 ssf=56 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 RESULT tag=97 err=0 text= > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 do_search: invalid dn > (basedn) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 SEARCH RESULT tag=101 err=34 > nentries=0 text=invalid DN > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 closed (connection lost) > > > Since the actual search is not logged, there is no way to determine what the > invalid DN being used is in this case. This seems faulty. I'd expect to see > some additional logging like: The invalid DN *was* logged, it was "basedn". Sounds like you have a really badly configured client out there somewhere. Closing this ITS... -- -- 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#6372) slapd lockup on shutdown
by quanah＠zimbra.com 10 Nov '09

10 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Had an idle slapd lock up during shutdown. Backtrace as follows: Thread 10 (process 627): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=2) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #5 <signal handler called> #6 0x0000003c0c706ffb in pthread_join () from /lib64/tls/libpthread.so.0 #7 0x0000002a956b2408 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 #8 0x0000000000431c8c in slapd_daemon () at daemon.c:2835 #9 0x00000000004146d8 in main (argc=10, argv=0x7fbfffae38) at main.c:950 Thread 9 (process 637): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 8 (process 636): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #4 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #5 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #6 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 7 (process 635): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 6 (process 634): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 5 (process 633): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 4 (process 632): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 3 (process 631): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 2 (process 630): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 1 (process 629): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x000000000042d17d in slapd_clr_write (s=4113, wake=1) at daemon.c:951 #5 0x0000000000433ae8 in connection_wake_writers (c=0x1451ec0) at connection.c:778 #6 0x0000000000433c40 in connection_closing (c=0x1451ec0, why=0x4e3ee2 "slapd shutdown") at connection.c:806 #7 0x00000000004322bb in connections_shutdown () at connection.c:209 #8 0x0000000000431b31 in slapd_daemon_task (ptr=0x0) at daemon.c:2761 #9 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by mbackes＠symas.com 10 Nov '09

10 Nov '09

Hello, Aleksey. > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with > the make install STRIP="" Okay. > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) At the same time? Your ldd list below shows only berkeley db 4.6. These don't mix... > In slapd config added using hdb as backend and indexes. Testing > database consist of 1000 users accounts with minimum attributes. On > stress test load slapd Segmentation fault in 10-30 sec. What sort of operations? > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 Does it always fail at the same location? How reproducible is this? Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#6371) problem with ber_flatten2
by dave.daugherty＠centrify.com 10 Nov '09

10 Nov '09

Full_Name: Dave Daugherty Version: 2.2.6 and 2.4.17 OS: RedHat EL3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.170.119.248) We use ber_flatten2 in an unusual way, but I think this issue is generic int ber_flatten2( BerElement *ber, struct berval *bv, int alloc ) { /* copy the berval */ ber_len_t len = ber_pvt_ber_write( ber ); if ( alloc ) { bv->bv_val = (char *) ber_memalloc_x( len + 1, ber->ber_memctx ); if ( bv->bv_val == NULL ) { return -1; } AC_MEMCPY( bv->bv_val, ber->ber_buf, len ); } else { bv->bv_val = ber->ber_buf; } bv->bv_val[len] = '\0'; <- ???? bv->bv_len = len; The problem I have is a crash, because of the bv->bv_val[len] = \0 when alloc is set to zero, AND the buffer that was passed in was generated by ber_realloc, which did not leave an extra byte at the end, resulting in a write beyond the allocated memory block. The questions I have are: 1) Is the zero terminator really necessary? 2) If so, seems like it should only be done if we actually allocated a new buffer (which does leave one byte at the end).

1 0

Re: (ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

Fixed in HEAD, servers/slapd/overlays/syncprov.c 1.289 -> 1.290 Please test. The fix should apply smoothly to recent 2.4 releases. Thanks for reporting, p.

1 0

(ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by kblaney＠nortel.com 10 Nov '09

10 Nov '09

Full_Name: Kyle Blaney Version: 2.4.15 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.187) In OpenLDAP 2.4.19, values change when converting from the syncprov-checkpoint option in file-based configuration to the olcSpCheckpoint attribute in online configuration. To reproduce: 1. Configure OpenLDAP using file-based slapd.conf configuration that contains the following line: syncprov-checkpoint 100 10 2. Make slapd.d directory. 3. Convert file-based configuration to online configuration using the following command: slapd -f slapd.conf -F slapd.d File-based configuration is converted to the cn=config database, but after conversion the value of the olcSpCheckpoint attribute in the "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config entry" is "100 600" when it should be the same as in file-based configuration ("100 10").

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2009