openldap-bugs June 2009

openldap-bugs@openldap.org

41 participants
115 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2009