openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5241) slapd crashes with "loglevel 0"
by Ulrich.Windl＠rz.uni-regensburg.de 23 Nov '07

23 Nov '07

Full_Name: Ulrich Windl Version: 2.3.32 OS: SLES10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.156.178) The version of OpenLDAP shipped with SUSE Linux Enterprise Server 10 (SLES10) SP1, openldap2-2.3.32-0.23 crashes with a segmentation fault if "loglevel 0" is used. For other log levels things seem to work. The problem has been seen on x86_64 (segfaults are logged in syslog).

1 0

ITS#5240
by ando＠sys-net.it 22 Nov '07

22 Nov '07

A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; init.c not yet). I don't know if it was intended, or if the merging is just in progress. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 22 Nov '07

22 Nov '07

Dan Oscarsson wrote: > ons 2007-11-21 klockan 23:53 -0800 skrev Howard Chu: > >>> I did a quick look at the code for bdb_cache_modrdn to see what have >>> been changed. Cannot say if it looks correct but I have one question >>> for the part: >> Thanks for checking, you're right. Now fixed in rev 1.161. > > I have now tested with latest out of CVS with the BerkeleyDB needed for > that. All my tests worked OK. > I have also updated the modrdn code in cache.c from your new code, in > the 2.3.38 version, and then tested. All tests is ok there too. > > I have now changed som data and run the tests again without any problem > in 2.3.38. So it looks good so far. As you said you plan to release > 2.4.7 soon, I will run my patched 2.3.38 util then, and then switch to > 2.4.7. I will run my old commercial ldap server and the openldap server > in parallell for a while to verify that no new problem is found. Thanks for the followup. Just a note - you don't need to use a particular version of BerkeleyDB with the CVS code; the same BDB 4.2.52 will keep working. But of course there are performance improvements in BDB 4.6... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5240) Build fails: incompatible type for argument 1 of 'ch_free'
by michael＠stroeder.com 22 Nov '07

22 Nov '07

Full_Name: Michael Ströder Version: RE24 OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.19.96) RE24 was synced right now. /bin/sh ../../..//libtool --tag=disable-static --mode=compile cc -g -O4 -march=pentium4 -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/opt/db-4.5/include -I/usr/include -I/opt/heimdal/include -DBDB_MONITOR_IDX -DSLAPD_IMPORT -c init.c mkdir .libs cc -g -O4 -march=pentium4 -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/opt/db-4.5/include -I/usr/include -I/opt/heimdal/include -DBDB_MONITOR_IDX -DSLAPD_IMPORT -c init.c -fPIC -DPIC -o .libs/init.o init.c: In function 'hdb_db_open': init.c:457: error: incompatible types in assignment init.c: In function 'hdb_db_close': init.c:549: error: incompatible type for argument 1 of 'ch_free' make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-hdb' make[2]: *** [back-hdb] Error 2 make[2]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 21 Nov '07

21 Nov '07

hyc(a)symas.com wrote: > I think that's enough to confirm the problems. I won't be able to work on the > fix for a few hours; will update here when I have something ready. You can test back-bdb/cache.c rev 1.160. I think you'll need to apply the diff between 1.157 - 1.160 to whatever source version you're currently using. (Or just use the CVS HEAD source.) -- -- Howard Chu Chief Architect, 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#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 21 Nov '07

21 Nov '07

Ok, the fix has been ported to RE24 and the testcase is enabled again. -- Ralf

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 21 Nov '07

21 Nov '07

Dan Oscarsson wrote: > tis 2007-11-20 klockan 07:09 -0800 skrev Howard Chu: >> Dan.Oscarsson(a)tietoenator.com wrote: >>> If this looks correct to you, what code should I add to fix it? >>> It would be better if one of you who knows the code better than me could >>> do that. I can test and see if it works. > >> Thanks for your investigation; this explanation makes sense. You can test this >> simply by disabling the statement in bdb_cache_modrdn() which sets the NO_KIDS >> flags: > > I have tested and it fixed my reduced test case. Running full test still > failes. > So I suspected it might have to do with CACHE_ENTRY_NO_GRANDKIDS > and tested by removing the test for CACHE_ENTRY_NO_GRANDKIDS in dn2id.c > *************** > *** 1044,1058 **** > if ( cx->prefix == DN_SUBTREE_PREFIX ) { > bdb_idl_append( cx->ids, cx->tmp ); > cx->need_sort = 1; > ! /*if ( !(cx->ei->bei_state & CACHE_ENTRY_NO_GRANDKIDS)) {*/ > ! { > > to get it to go down in the tree. > > This time even my full test works, from what I can see. Though this may > not be the correct way to do it, and I do not know if something else > may go wrong. > It looks like the setting and usage of CACHE_ENTRY_NO_GRANDKIDS and > CACHE_ENTRY_NO_KIDS have to be looked over. From what I can see they are > only used in cache.c, dn2id.c and modrdn.c in back-bdb/hdb. > Should I try something else? I think that's enough to confirm the problems. I won't be able to work on the fix for a few hours; will update here when I have something ready. -- -- Howard Chu Chief Architect, 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#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 21 Nov '07

21 Nov '07

tis 2007-11-20 klockan 07:09 -0800 skrev Howard Chu: > Dan.Oscarsson(a)tietoenator.com wrote: > > If this looks correct to you, what code should I add to fix it? > > It would be better if one of you who knows the code better than me could > > do that. I can test and see if it works. > > > Thanks for your investigation; this explanation makes sense. You can test this > simply by disabling the statement in bdb_cache_modrdn() which sets the NO_KIDS > flags: I have tested and it fixed my reduced test case. Running full test still failes. So I suspected it might have to do with CACHE_ENTRY_NO_GRANDKIDS and tested by removing the test for CACHE_ENTRY_NO_GRANDKIDS in dn2id.c *************** *** 1044,1058 **** if ( cx->prefix == DN_SUBTREE_PREFIX ) { bdb_idl_append( cx->ids, cx->tmp ); cx->need_sort = 1; ! /*if ( !(cx->ei->bei_state & CACHE_ENTRY_NO_GRANDKIDS)) {*/ ! { to get it to go down in the tree. This time even my full test works, from what I can see. Though this may not be the correct way to do it, and I do not know if something else may go wrong. It looks like the setting and usage of CACHE_ENTRY_NO_GRANDKIDS and CACHE_ENTRY_NO_KIDS have to be looked over. From what I can see they are only used in cache.c, dn2id.c and modrdn.c in back-bdb/hdb. Should I try something else? Regards, Dan -- Dan Oscarsson TietoEnator Email: Dan.Oscarsson(a)tietoenator.com Box 85 201 20 Malmo, Sweden

1 0

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 21 Nov '07

21 Nov '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On November 15, 2007 9:22:41 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.231.219) > > Dieter, > > Can you confirm one way or the other if the fix in HEAD from > Pierangelo solved your issue? I just did a cvs update of HEAD and did a few tests. As I get now errors it seems that this ITS is solved now. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#5239) Ordered indexing for integers (Enhancement)
by hyc＠OpenLDAP.org 20 Nov '07

20 Nov '07

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Support for ordered indexing of integer attributes is now in HEAD.

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