openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6310) Slapd with pcache crashes under load
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

> masarati(a)aero.polimi.it wrote: >> I didn't make any progress in debugging your issue, as I can't reproduce >> your issue using your configuration. What you see, namely some >> cacheability/answerability messages without a request could be related >> to >> pcache intercepting some internal operation, e.g. related to ACL >> checking? >> This could be intended or a mistake, but I can't tell so far. >> >> As a side note, your configuration seems to be triggering some issues in >> back-ldap. In detail, you set a rootdn, which is probably needed by >> slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm >> investigating this a little bit further, although it might not be >> related >> to your issue. >> >> p. > Yes, I have set up rootdn because pcache overlay wanted it. I will set > also some rootpw to see if this makes difference. mmmh, sounds like a red herring, sorry for the noise. p.

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by karavelov＠spnet.net 07 Oct '09

07 Oct '09

masarati(a)aero.polimi.it wrote: > I didn't make any progress in debugging your issue, as I can't reproduce > your issue using your configuration. What you see, namely some > cacheability/answerability messages without a request could be related to > pcache intercepting some internal operation, e.g. related to ACL checking? > This could be intended or a mistake, but I can't tell so far. > > As a side note, your configuration seems to be triggering some issues in > back-ldap. In detail, you set a rootdn, which is probably needed by > slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm > investigating this a little bit further, although it might not be related > to your issue. > > p. Yes, I have set up rootdn because pcache overlay wanted it. I will set also some rootpw to see if this makes difference. Luben

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

I didn't make any progress in debugging your issue, as I can't reproduce your issue using your configuration. What you see, namely some cacheability/answerability messages without a request could be related to pcache intercepting some internal operation, e.g. related to ACL checking? This could be intended or a mistake, but I can't tell so far. As a side note, your configuration seems to be triggering some issues in back-ldap. In detail, you set a rootdn, which is probably needed by slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm investigating this a little bit further, although it might not be related to your issue. p.

1 0

(ITS#6326) back-ldap may leak when building entry with undef objectClass
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.251) Submitted by: ando The name of the undef objectClass is copied, but never used, and the pointer is lost. A fix is coming... p.

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by jwm＠horde.net 07 Oct '09

07 Oct '09

On Wed, Oct 07, 2009 at 08:02:53PM +0200, masarati(a)aero.polimi.it wrote: > Should be fixed now. Thanks. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

>> Please check the fix in HEAD. I can't check right now on x86_64, but >> I'll >> probably do it tomorrow. Apparently, I didn't break anything on 32 bit. > > 'slapd -d ?' still lists the 64-bit value for LDAP_DEBUG_ANY on x86_64: > > -- > Installed log subsystems: > > Any (18446744073709551615) > [...] > -- > > As I mentioned, this is due to the unsigned long format specifier (%lu) in > loglevel_print(). Changing the format specifier to %u emits the correct > value (4294967295) on this architecture. > > With your fix, slapd accepts the numeric value 4294967295 for > LDAP_DEBUG_ANY on x86_64. Should be fixed now. Also, please note the slightly changed behavior: the decimal *and* the hexadecimal value are both printed. This can be reversed if anyone fears it breaks anything. Thanks, p.

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by karavelov＠spnet.net 07 Oct '09

07 Oct '09

masarati(a)aero.polimi.it wrote: > No. Some overlay along the lines apparently mucks with e_private in the > entry that back-ldap is sending. It's probably slapo-pcache. I need to > debug this. You say it happens seldom. Can you recognize anything > special in the operation that triggers the assertion failure? I mean: > either in terms of special data, or in terms of special state of the > cache? This could help narrow down some means to reproduce the issue. > > Thanks, p. I have enabled full debugging info in the logs. So here are the last 1000 lines from the last abort: http://purgatory.spnet.net/~karavelov/abort/slapd.log.9004 I looked closely the generated core. Here is the gdb session: http://purgatory.spnet.net/~karavelov/abort/gdb.9004 Tell me if I could check some other variables that could help you identify the problem. Luben

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

jwm(a)horde.net wrote: > On Tue, Oct 06, 2009 at 10:04:45PM +0200, masarati(a)aero.polimi.it wrote: >>> The 32-bit value 4294967295 for LDAP_DEBUG_ANY is also rejected. >>> lutil_atoix() declares i as type long and tries to check for overflow(?) >>> with this cast: >>> >>> if ( (long)(int)i != i ) { >>> >>> which always fails in this case on x86_64. lutil_atoux() might be the more >>> appropriate choice here. >>> >>> str2loglevel() seems to behave correctly by virtue of verb_to_mask() >>> returning an index into loglevel_ops, but I haven't checked extensively. >>> loglevel_init(), however, does specify a hardcoded -1 for the Any level >>> instead of LDAP_DEBUG_ANY. >> Please check the fix in HEAD. I can't check right now on x86_64, but I'll >> probably do it tomorrow. Apparently, I didn't break anything on 32 bit. > > 'slapd -d ?' still lists the 64-bit value for LDAP_DEBUG_ANY on x86_64: > > -- > Installed log subsystems: > > Any (18446744073709551615) > [...] > -- > > As I mentioned, this is due to the unsigned long format specifier (%lu) in > loglevel_print(). Changing the format specifier to %u emits the correct > value (4294967295) on this architecture. > > With your fix, slapd accepts the numeric value 4294967295 for > LDAP_DEBUG_ANY on x86_64. OK, I overlooked that. My point was to make sure unsigned values are correctly cast into (unsigned)-1 by routines intended to deal with integers. I'll fix that again. Thanks, p.

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by jwm＠horde.net 07 Oct '09

07 Oct '09

On Tue, Oct 06, 2009 at 10:04:45PM +0200, masarati(a)aero.polimi.it wrote: > > The 32-bit value 4294967295 for LDAP_DEBUG_ANY is also rejected. > > lutil_atoix() declares i as type long and tries to check for overflow(?) > > with this cast: > > > > if ( (long)(int)i != i ) { > > > > which always fails in this case on x86_64. lutil_atoux() might be the more > > appropriate choice here. > > > > str2loglevel() seems to behave correctly by virtue of verb_to_mask() > > returning an index into loglevel_ops, but I haven't checked extensively. > > loglevel_init(), however, does specify a hardcoded -1 for the Any level > > instead of LDAP_DEBUG_ANY. > > Please check the fix in HEAD. I can't check right now on x86_64, but I'll > probably do it tomorrow. Apparently, I didn't break anything on 32 bit. 'slapd -d ?' still lists the 64-bit value for LDAP_DEBUG_ANY on x86_64: -- Installed log subsystems: Any (18446744073709551615) [...] -- As I mentioned, this is due to the unsigned long format specifier (%lu) in loglevel_print(). Changing the format specifier to %u emits the correct value (4294967295) on this architecture. With your fix, slapd accepts the numeric value 4294967295 for LDAP_DEBUG_ANY on x86_64. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 07 Oct '09

07 Oct '09

Download testrun/ here: http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz

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