- openldap-bugs - openldap.org

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 29 Jun '09

29 Jun '09

--001636c5b621da4708046d784a4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I still reproduce this problem with 2.4.17-prerelease. I have a client that request a lof of operations at the same time through a connection. The slapd seems to overload and finally close the connection sending a reset to the client and when this happens the connection hungs eating the CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the same point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I still reproduce this problem with 2.4.17-prerelease. I have= a client that request a lof of operations at the same time through a conne= ction. The slapd seems to overload and finally close the connection sending= a reset to the client and when this happens the connection hungs eating th= e CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the sa= me point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e--

1 0

Re: (ITS#6189) test056 failure
by hyc＠symas.com 28 Jun '09

28 Jun '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html > > Note that the proposed fix may mean revisiting ITS#3850. > Without the patch in HEAD, test056 failed after 21 iterations on my OpenSUSE system. With the patch it ran 1000 iterations successfully. -- -- 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#6189) test056 failure
by hyc＠OpenLDAP.org 27 Jun '09

27 Jun '09

Full_Name: Howard Chu Version: RE24/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html Note that the proposed fix may mean revisiting ITS#3850.

1 0

potential bug
by Rahul Amaram 26 Jun '09

26 Jun '09

Hi, While working with OpenLDAP, I've observed something strange. I am not sure if this is the anticipated behaviour. Let us say we have two attributes 'name' and 'middleName' and the former is the superior of the latter i.e. attributetype ( 1.3.6.1.4.74 NAME 'middleName' SUP name ) Now let us assume that the value of the attribute 'middleName' for a particular dn is 'Konda'. Then performing a search on the basedn with the filter "(name=Konda)" returns that particular dn. Is this a bug or anticipated behaviour? Regards, Rahul.

3 3

Re: (ITS#6185) test033-glue-syncrepl failed
by hyc＠symas.com 26 Jun '09

26 Jun '09

richton(a)nbcs.rutgers.edu wrote: > slapd-glue-syncrepl1.conf 1.17 > slapd-glue-syncrepl2.conf 1.17 > > has tested well for about twelve hours of continuous loop. I think this is > good now. Great, thanks for the confirmation. -- -- 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#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 26 Jun '09

26 Jun '09

slapd-glue-syncrepl1.conf 1.17 slapd-glue-syncrepl2.conf 1.17 has tested well for about twelve hours of continuous loop. I think this is good now.

1 0

Re: (ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 25 Jun '09

25 Jun '09

The question came up if this was new post-2.4.16. I recompiled 2.4.16 and ran test033 for 30 hours with no failures. I've now switched back to HEAD, and I found first failure in a bit under three hours. (Note that when I found this, I was running all tests, not only 033. With 2.4.16 and today's HEAD run, I'm looping test033 only, because at this point it's the only place I'm seeing failures.)

1 0

(ITS#6188) ldap_pvt_thread_pool_retract needs a stub
by richton＠nbcs.rutgers.edu 25 Jun '09

25 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: Submission from: (NULL) (128.6.31.135) to allow --without-threads to link. I, Aaron Richton, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --- thr_stub.c~ 2009-06-25 14:04:22.000000000 -0400 +++ thr_stub.c 2009-06-25 14:14:39.000000000 -0400 @@ -167,6 +167,14 @@ } int +ldap_pvt_thread_pool_retract ( + ldap_pvt_thread_pool_t *tpool, + ldap_pvt_thread_start_t *start_routine, void *arg ) +{ + return(0); +} + +int ldap_pvt_thread_pool_maxthreads ( ldap_pvt_thread_pool_t *tpool, int max_threads ) { return(0);

1 0

(ITS#6187) release page update
by quanah＠OpenLDAP.org 25 Jun '09

25 Jun '09

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) This page: http://www.openldap.org/software/roadmap.html needs updating. 2.3 is no longer a current release.

1 0

Re: (ITS#5535) smbk5pwd uses private heimdal functions
by Guillaume.Rousse＠inria.fr 24 Jun '09

24 Jun '09

The patch is course usable for integration in openldap (I originaly posted it on the list precisely for this purpose, sorry if I wasn't clear enough).

1 0

(ITS#6174) Backtrace for a segfault
by frank.offermanns＠caseris.de 24 Jun '09

24 Jun '09

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002BEC64C12575DF_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, for this test setup i got an empty database and tried to add 20000 Users=20 under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at server1 (windos vista) while try= ing=20 to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestxp at server2 (Windo= ws=20 XP). The slapd.exe on the XP Server crashed. Compiled the version from=20 HEAD with Mingw/MSYS for windows. The servers are configured as stated in my previos post (multimaster). Here comes the backtrace of the segfault: I am new to gdb debbuging to please feel free to tell me if you need=20 addtional info (it would be nice if you would tell me the commands to do=20 so). Starting program: C:\all/slapd.exe -F slapd.d [New thread 2580.0x36c] [New thread 2580.0x550] [New thread 2580.0xbfc] [New thread 2580.0xad8] [New thread 2580.0x714] [New thread 2580.0xe90] [New thread 2580.0xcec] [New thread 2580.0x37c] [New thread 2580.0x108] [New thread 2580.0x1a8] [New thread 2580.0x1dc] [New thread 2580.0xd28] [New thread 2580.0x564] [New thread 2580.0xf50] [New thread 2580.0x29c] [New thread 2580.0xfdc] Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2580.0xe90] 0x004cd88f in syncprov=5Fop=5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8) at=20 syncprov.c:1970 1970 for ( m2 =3D mt->mt=5Fmods;= =20 m2->mi=5Fn ext !=3D mi; (gdb) bt #0 0x004cd88f in syncprov=5Fop=5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8) at syncprov.c:1970 #1 0x0048994a in overlay=5Fop=5Fwalk (op=3D0xd8e5e38, rs=3D0x4adfce8, which=3Dop=5Fmodify, oi=3D0xffbe70, on=3D0xf82df0) at backover.c:659 #2 0x00489b74 in over=5Fop=5Ffunc (op=3D0xd8e5e38, rs=3D0x4adfce8,=20 which=3Dop=5Fmodify) at backover.c:721 #3 0x00489c49 in over=5Fop=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at backover.c:755 #4 0x004355c1 in fe=5Fop=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at=20 modify.c:301 #5 0x0043508f in do=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:= 175 #6 0x0041c8f0 in connection=5Foperation (ctx=3D0x4adfdd8, arg=5Fv=3D0xd8e5= e38) at connection.c:1115 #7 0x0041cdb6 in connection=5Fread=5Fthread (ctx=3D0x4adfdd8, argv=3D0x7) at connection.c:1248 #8 0x00504621 in ldap=5Fint=5Fthread=5Fpool=5Fwrapper () #9 0x77c0a3b0 in msvcrt!=5Fendthreadex () from=20 C:\WINDOWS\system32\msvcrt.dll #10 0x7c80b699 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #11 0x00000000 in ?? () Best regards, Frank Offermanns - Frank Offermanns | Entwicklung | CASERIS GmbH=20 Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= t=20 Aachen, HRB 14758 --=_alternative 002BEC64C12575DF_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, for this test setup i got an empty d= atabase and tried to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at ser= ver1 (windos vista) while trying to add 20000 Users under o=3Dcaesar,ou=3DUsers,= o=3Dtestxp at server2 (Windows XP). The slapd.exe on the XP Server crashed. Compiled the version from HEAD with Mingw/MSYS for windows. The servers are configured as stated in my previos post (multimaster). Here comes the backtrace of the segf= ault: I am new to gdb debbuging to please feel free to tell me if you need addtional info (it would be nice if you would tell me the commands to do so). Starting program: C:\all/slapd.exe -F slapd.d [New thread 2580.0x36c] [New thread 2580.0x550] [New thread 2580.0xbfc] [New thread 2580.0xad8] [New thread 2580.0x714] [New thread 2580.0xe90] [New thread 2580.0xcec] [New thread 2580.0x37c] [New thread 2580.0x108] [New thread 2580.0x1a8] [New thread 2580.0x1dc] [New thread 2580.0xd28] [New thread 2580.0x564] [New thread 2580.0xf50] [New thread 2580.0x29c] [New thread 2580.0xfdc] Program received signal SIGSEGV, Seg= mentation fault. [Switching to thread 2580.0xe90]</fo= nt> 0x004cd88f in syncprov=5Fop=5Fmod (o= p=3D0xd8e5e38, rs=3D0x4adfce8) at syncprov.c:1970 1970         &nb= sp;                                  for ( m2 =3D mt->mt=5Fmods; m2-= >mi=5Fn ext !=3D mi; (gdb) bt #0  0x004cd88f in syncprov=5Fop= =5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8)     at syncprov.c:1970</fo= nt> #1  0x0048994a in overlay=5Fop= =5Fwalk (op=3D0xd8e5e38, rs=3D0x4adfce8,     which=3Dop=5Fmodify, o= i=3D0xffbe70, on=3D0xf82df0) at backover.c:659 #2  0x00489b74 in over=5Fop=5Ff= unc (op=3D0xd8e5e38, rs=3D0x4adfce8, which=3Dop=5Fmodify)     at backover.c:721</fon= t> #3  0x00489c49 in over=5Fop=5Fm= odify (op=3D0xd8e5e38, rs=3D0x4adfce8)     at backover.c:755</fon= t> #4  0x004355c1 in fe=5Fop=5Fmod= ify (op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:301 #5  0x0043508f in do=5Fmodify (= op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:175 #6  0x0041c8f0 in connection=5F= operation (ctx=3D0x4adfdd8, arg=5Fv=3D0xd8e5e38)     at connection.c:1115</= font> #7  0x0041cdb6 in connection=5F= read=5Fthread (ctx=3D0x4adfdd8, argv=3D0x7)     at connection.c:1248</= font> #8  0x00504621 in ldap=5Fint=5F= thread=5Fpool=5Fwrapper () #9  0x77c0a3b0 in msvcrt!=5Fend= threadex () from C:\WINDOWS\system32\msvcrt.dll #10 0x7c80b699 in KERNEL32!GetModule= FileNameA ()    from C:\WINDOWS\system3= 2\kernel32.dll #11 0x00000000 in ?? () Best regards, Frank Offermanns - Frank Offermanns | Entw= icklung | <a href=3Dhttp://www.caseris.de/>CASERIS GmbH</a> Fon: +49 2402 7654-566<= /font> Fax: +49 2402 7654-8566= | E-Mail: <a href=3Dmailto:Frank.Offermanns@caseris.com>Frank.Offermanns(a)caseris.com</= a> -- CASERIS GmbH | Am Birke= nfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dip= l.-Ing. Stefan Preu=DF | Registergericht: Amtsgericht Aachen, HRB 14758 --=_alternative 002BEC64C12575DF_=--

1 0

Re: (ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 23 Jun '09

23 Jun '09

--001485f1e78e38f960046d0c351a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please note Guillaume.Rousse(a)inria.fr is the author of the patch i supplied. Origin: http://www.stacken.kth.se/lists/heimdal-discuss/2008-05/msg00107.html --001485f1e78e38f960046d0c351a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please note <a href=3D"mailto:Guillaume.Rousse@inria.fr">Guillaume.Rousse@i= nria.fr</a> =A0is the author of the patch i supplied. Origin: <a href=3D"http://www.sta= cken.kth.se/lists/heimdal-discuss/2008-05/msg00107.html">http://www.stacken= .kth.se/lists/heimdal-discuss/2008-05/msg00107.html</a> --001485f1e78e38f960046d0c351a--

1 0

Re: (ITS#6186) sizelimit broken
by hyc＠symas.com 23 Jun '09

23 Jun '09

christian.fischer(a)fischundfischer.com wrote: > Full_Name: Christian Fischer > Version: 2.4.16 > OS: gentoo amd64 > URL: > Submission from: (NULL) (213.221.82.34) > > > slapd ignores sizelimit values above 500 and -1 (unlimited) > > If sizelimit is set to a value>=0 and<=500 the behavior is as expected, > unlimited > (-1) and values>500 are ignored. > > I've turned on args debugging to see if something is different between 2.4.16 > and 2.3.43, which works for me. > > Version 2.3.43 op->ors_slimit is set to 0 if do_search() is executed, > version 2.4.16 op->ors_slimit is set to 500 (SLAPD_DEFAULT_SIZELIMIT). > > That explains the different behavior of limits_check(). > > With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into > servers/slapd/limits.c:1294 and ors_slimit will only set to > ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1 and > SLAPD_DEFAULT_SIZELIMIT -1. Your explanation is a bit unclear. Please provide an ldapsearch commandline that demonstrates the problem with the slapd.conf you provided. When a given sizelimit is configured on the server, what values of sizelimit requested by the client are working correctly or incorrectly? -- -- 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#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

The only connection issue I'm still seeing is #5733...I believe this is resolved in modern code.

1 0

(ITS#6186) sizelimit broken
by christian.fischer＠fischundfischer.com 23 Jun '09

23 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) slapd ignores sizelimit values above 500 and -1 (unlimited) If sizelimit is set to a value >=0 and <=500 the behavior is as expected, unlimited (-1) and values >500 are ignored. I've turned on args debugging to see if something is different between 2.4.16 and 2.3.43, which works for me. Version 2.3.43 op->ors_slimit is set to 0 if do_search() is executed, version 2.4.16 op->ors_slimit is set to 500 (SLAPD_DEFAULT_SIZELIMIT). That explains the different behavior of limits_check(). With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into servers/slapd/limits.c:1294 and ors_slimit will only set to ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1 and SLAPD_DEFAULT_SIZELIMIT -1. This patch has solved my problem for now, sizelimit statement is working without restrictions. --- openldap-2.4.16/servers/slapd_orig/limits.c 2009-01-22 01:01:01.000000000 +0100 +++ openldap-2.4.16/servers/slapd/limits.c 2009-06-15 09:27:36.212817654 +0200 @@ -1077,6 +1077,9 @@ return 0; } + /* fix sizelimit */ + op->ors_slimit = 0; + /* allow root to set no limit */ if ( be_isroot( op ) ) { op->ors_limit = NULL; ### config snippet ### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/openssh-lpk.schema include /etc/openldap/schema/radius.schema include /etc/openldap/schema/egr.schema include /etc/openldap/schema/mozillaabpersonalpha.schema include /etc/openldap/schema/dhcp.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCertificateFile /etc/openldap/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/openldap/ssl/ca.crt TLSVerifyClient never loglevel none serverID 2 security ssf=256 disallow bind_anon require authc database bdb suffix "dc=foo,dc=bar" rootdn "cn=Manager,dc=foo,dc=bar" rootpw secret directory /var/lib/openldap-data checkpoint 32 30 sizelimit unlimited index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE syncrepl rid=123 provider=ldap://isc01.foo.bar starttls=yes tls_reqcert=never type=refreshAndPersist retry="5 5 60 +" searchbase="dc=foo,dc=bar" scope=sub schemachecking=on bindmethod=simple binddn="cn=syncrepl,ou=dsa,dc=foo,dc=bar" credentials=secret mirrormode on ### ACL ### # [snip]

1 0

Re: (ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

This appears to be semi-regular; I have two more substantially identical testrun directories indicating failure.

1 0

Re: ITS#6101 Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 23 Jun '09

23 Jun '09

hyc(a)symas.com writes: > What do you mean by "components are commonly used uninitialized" ? > Have you actually seen cases where the code reads these values before > they are init'd? Certainly valgrind never trips over them. There is nothing for Valgrind to trip over if the compiler zero-fills rs.sr_un union when it sees SlapReply rs = {REP_RESULT}; However, add this in slap.h, which is all the compiler needs to emit for that initialization: #define DECL_SlapReply(name, type) \ SlapReply name; \ name.sr_type = 0; \ name.sr_tag = 0; \ name.sr_msgid = 0; \ name.sr_err = 0; \ name.sr_matched = 0;\ name.sr_text = 0; \ name.sr_ref = 0; \ name.sr_ctrls = 0; \ name.sr_un.sru_sasl.r_sasldata = 0; \ name.sr_flags = 0 Replace current initializations with that as follows: grep -l 'SlapReply[<tab> ][a-z0-9]* *=' *.c */*.c | xargs perl -i -pe ' s/^(\t+)(SlapReply)\s+(\w+)\s*=\s*{\s*(\w+)\s*}\;/$1DECL_$2($3, $4)\;/' (type ctrl-v tab in shell for the<tab>) Compile with C99 or gcc extension mode to allow mixed code and decls. make test doesn't even survive test000. And yes, valgrind is annoyed. -- Hallvard

1 0

Re: (ITS#6184) slapd segmentation fault
by michael＠stroeder.com 23 Jun '09

23 Jun '09

jginsberg(a)thehive.com wrote: > > I'm not sure I'm really comfortable with running a pre-release 2.4.16 is the currently STABLE release. You should definitely use that instead of 2.4.15. See also: http://www.openldap.org/faq/data/cache/225.html Ciao, Michael.

1 0

ITS#6101 Uninitialized SlapReply components
by hyc＠symas.com 22 Jun '09

22 Jun '09

What do you mean by "components are commonly used uninitialized" ? Have you actually seen cases where the code reads these values before they are init'd? Certainly valgrind never trips over them. -- -- 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#6170) test039 seg faults
by hyc＠symas.com 22 Jun '09

22 Jun '09

michael(a)stroeder.com wrote: > Seg faulted again. > > Take two of tests/testrun/ available under: > > http://www.stroeder.com/temp/openldap/its6170_test039-testrun2.tar.gz > > I really wonder why I have such subtle issues which are not > deterministic. Maybe it's because I'm running make test on an old laptop > with Pentium Mobile 1,8 GHz which is rather slow? > > I tested with default values SLEEP1=7 and SLEEP2=15. Even if these > values are too low for this particular system slapd should never ever > seg fault. Same trace as #5733, closing this ITS as a dup. -- -- 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#6174) Permanent high CPU Load with Multimaster
by hyc＠symas.com 22 Jun '09

22 Jun '09

Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.16 > OS: Windows XP/Ubuntu 9.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > Hello everyone, > > I compiled the LDAP Version 2.4.16 from CVS at 16 June with MINGW/MSYS on > Windows. I used the latest version because every previous 2.4.16 version had > similar problems. There is no "latest 2.4.16" version. There is only one release with version number 2.4.16, whether you got it from CVS or from the web site. > I have two systems working together as multimasters. After a random time (less > than a day) it can happen, that a core of a CPU uses 100 % CPU Load. Both System > seems to be working correctly, but the High CPU Load slows down everything. > No matter how long i wait, this core stays at 100 % CPU load. > On another test a test write operation never returned and I also had the high > CPU load. After i killed my test write process, the slapd.exe crashed. (The > write procees was on a another PC) Use gdb to get traces of the active threads when the 100% CPU situation occurs. Likewise, use gdb to get traces when slapd crashes. -- -- 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#6184) slapd segmentation fault
by jginsberg＠thehive.com 22 Jun '09

22 Jun '09

Hi Quanah -- I'm not sure I'm really comfortable with running a pre-release -- this is for our corporate identity and contact management server, and it is as mission critical as that sounds. It was enough of a headache running it under production load inside gdb to get the stack trace. :-) The workaround we've employed for the timebeing is switching to the bdb backend and using monit to keep an eye on things. We'll look forward to seeing what comes out in 2.4.17 and re-evaluate then. Thanks! -jag On Jun 22, 2009, at 5:31 PM, Quanah Gibson-Mount wrote: > --On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com > wrote: > >> Full_Name: Joshua Ginsberg >> Version: 2.4.15 >> OS: Debian lenny 2.6.29.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (208.78.90.5) > > There have been numerous fixes since 2.4.15 and 2.4.16. I suggest > you try the current CVS RE24 and see if you still have issues. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6184) slapd segmentation fault
by quanah＠zimbra.com 22 Jun '09

22 Jun '09

--On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com wrote: > Full_Name: Joshua Ginsberg > Version: 2.4.15 > OS: Debian lenny 2.6.29.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.78.90.5) There have been numerous fixes since 2.4.15 and 2.4.16. I suggest you try the current CVS RE24 and see if you still have issues. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 22 Jun '09

22 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/test033-testrun-200906221036.tar.gz Submission from: (NULL) (74.105.10.5) test033 *.flt differ. No seg fault/assertions, just unexpected results. testrun directory (includes -d -1) is in the linked tarball.

1 0

Re: (ITS#6184) slapd segmentation fault
by jginsberg＠thehive.com 22 Jun '09

22 Jun '09

To elaborate on our setup... We're running 2.4.15 compiled with openssl using two servers in syncrepl mirrormode using cn=config style configuration and the hdb backend. The OS is debian lenny, so we're using Debian's bdb version 4.6 package. Our server segfaults quite regularly under moderate production load -- because of the number of diverse users accessing the directory over numerous systems, I cannot identify a single trigger that causes the segmentation fault. -jag

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs