openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

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

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

07 Oct '09

Full_Name: Michael Ströder Version: 2.4.19 OS: SLES 10 URL: Submission from: (NULL) (84.163.54.11) slapd built with BDB 4.8.24 and cyrus-sasl 2.4RC1 >>>>> Starting test054-syncreplication-parallel-load for hdb... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify producer directory... Using ldappasswd to change some passwords... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Trying to change some passwords on the consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ >>>>> ./scripts/test054-syncreplication-parallel-load failed for hdb (exit 1) make[2]: *** [hdb-mod] Error 1 make[2]: Leaving directory `/source/openldap-2.4.19/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/source/openldap-2.4.19/tests' make: *** [test] Error 2

1 0

slapd crash on load
by Ключников А.С. 07 Oct '09

07 Oct '09

Good day. Openldap 2.4.18 with bdb backend used for pam_ldap and nss_ldap on freebsd7.2 amd64 Crashed every 10 - 30 minutes on serches. Load isnt heavy, about 10 req/sec in peak and 20req/min average. Crash probability is higher when over program use the disk. how to mo debug to resolve problem? Some details: #uname -a FreeBSD bazar 7.2-RELEASE FreeBSD 7.2-RELEASE #3: Tue Jun 9 16:46:20 MSD 2009 root@bazar:/usr/obj/usr/src/sys/GENERIC amd64 #/usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.18 (Oct 7 2009 13:29:25) tuning in slapd.conf cachesize 150000 idlcachesize 450000 #checkpoint 64 10 threads 8 concurrency 5 tuning in /var/db/openldap-data/DB_CONFIG set_cachesize 0 62428800 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /var/db/openldap-data crash debug whith truss /usr/local/libexec/slapd -d -1 _umtx_op(0x8022020b0,0x11,0x0,0x0,0x0,0x0) = 0 (0x0) gidNumber_umtx_op(0x8022020b0,0x11,0x0,0x0,0x0,0x7ffffda79308) = 10 (0xa) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,91,0x0,NULL,0x0) = 91 (0x5b) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffebfba28) = 0 (0x0) ber_scanf fmt ({im}) ber: write(2,"ber_scanf fmt ({im}) ber:\n",26) = 0 (0x0) ber_dump: buf=0x81141b408 ptr=0x81141b408 end=0x81141b414 len=12 gettimeofday({1254902373.820741 },0x0) = 65 (0x41) 0000: 30 84 00 00 00 06 02 02 03 e8 04 00 0........... write(2," 0000: 30 84 00 00 00 06 02 02"...,79) = 0 (0x0) <= get_ctrls: n=1 rc=0 err="" write(2,"<= get_ctrls: n=1 rc=0 err=""\n",30) = 30 (0x1e) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,106,0x0,NULL,0x0) = 106 (0x6a) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7fffff3fcaa8) = 0 (0x0) gettimeofday({1254902373.821208 },0x0) = 0 (0x0) ==> limits_get: conn=92 op=1 self="cn=bind,ou=staff,dc=ulgsm,dc=ru" this="ou=staff,dc=ulgsm,dc=ru" getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) _umtx_op(0x8022020b0,0x11,0x0,0x0,0x0,0x7fffff3fc648) = 105 (0x69) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffda79658) = 0 (0x0) gettimeofday({1254902373.821644 },0x0) = 34669068288 (0x812700000) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) => bdb_dn2idl("ou=staff,dc=ulgsm,dc=ru") sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,45,0x0,NULL,0x0) = 41 (0x29) _umtx_op(0x8022020b0,0x11,0x0,0x0,0x0,0x7ffffda79208) = 45 (0x2d) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffe3faaa8) = 0 (0x0) write(2,"\n",1) = 0 (0x0) _umtx_op(0x8022020b0,0x11,0x0,0x0,0x0,0x7ffffe3fa6e8) = 0 (0x0) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,64,0x0,NULL,0x0) = 64 (0x40) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffebfba28) = 0 (0x0) attrs:write(2," attrs:",10) = 0 (0x0) gettimeofday({1254902373.822603 },0x0) = 0 (0x0) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,45,0x0,NULL,0x0) = 45 (0x2d) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffebfbaa8) = 0 (0x0) cngettimeofday({1254902373.822938 },0x0) = 3 (0x3) getpid(0x80180bf68,0x7fffffffed70,0x0,0x0,0xffff80080f10aaaa,0x0) = 81516 (0x13e6c) sendto(3,"<167>Oct 7 11:59:33 slapd[81516"...,75,0x0,NULL,0x0) = 75 (0x4b) _umtx_op(0x8022020b0,0x12,0x0,0x0,0x0,0x7ffffda795c8) = 0 (0x0) SIGNAL 11 (SIGSEGV) -- alexs

1 0

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

06 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. > > > What is interesting is that most of the logs are something like this one: conn=6891 op=1 SRCH attr=spamassassin query template of incoming query = (&(objectClass=)(cn=)) Entering QC, querystr = (&(objectClass=mailUser)(cn=nobody)) Lock QC index = 0x7e0a7b8 QUERY ANSWERABLE (answered 3267 times) conn=6891 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= conn=6891 fd=32 closed (connection lost) query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE conn=3573 op=812 SRCH base="dc=ciela.net,dc=hosting,dc=spnet,dc=net" scope=1 deref=0 filter="(&(objectClass=mailUser)(uid=diana))" conn=3573 op=812 SRCH attr=uid userPassword mailMessageStore uidNumber gidNumber query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=mailUser)(uid=diana)) Lock QC index = 0x7ee9fe8 Base of added query = dc=ciela.net,dc=hosting,dc=spnet,dc=net QUERY ANSWERABLE (answered 63 times) conn=3573 op=812 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd: /home/luben/openldap-2.4.18-h/servers/slapd/entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. This sequence of : query template of incoming query = (&(objectClass=)(uid=)) QUERY NOT ANSWERABLE QUERY NOT CACHEABLE is something I could not explain. There is not a log entry for incomming search. I have restarted the cache with more logging (stats+trace+pcache) to see from where they come. I have some core dumps and if you tell me for what to look for, tomorrow I will debug them and see if there is a common pattern. Luben

1 0

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

06 Oct '09

> Hello, > I have somehow changed the setup: > > The first process is a ldap to sql server withpout pcache > the config file is here: > http://purgatory.spnet.net/~karavelov/abort/slapd.conf > > The second process is a pure cache that reads from the first process > using unix domain socket. The config file is here: > http://purgatory.spnet.net/~karavelov/abort/slapd-proxy.conf > > The sql backend runs without problems. But the proxy process crashes > once or twice a day on assertion: > > The output of the process is here: > http://purgatory.spnet.net/~karavelov/abort/log > > It was running in valgrind, so here is its output: > http://purgatory.spnet.net/~karavelov/abort/vg > > The process has dumped a core. I have made a debugging session with it. > Here it is: > http://purgatory.spnet.net/~karavelov/abort/gdb > > I am not sure what to look for. The process aborts on the same > asserrtion even it is not run in valgrind. 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.

1 0

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

06 Oct '09

> 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. Thanks, p.

1 0

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

06 Oct '09

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. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

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

06 Oct '09

Full_Name: John Morrissey Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) slapd -d ? emits the incorrect numeric value for LDAP_DEBUG_ANY on x86_64: $ slapd -d \? Installed log subsystems: Any (18446744073709551615) [...] $ slapd -d 18446744073709551615 unrecognized log level "18446744073709551615" Debug levels are always treated as type int, which is four bytes on Linux x86_64. loglevel_print() in servers/slapd/bconfig.c seems to blame, since it's using a long-typed format (%lu) instead of an unsigned int-typed one (%u).

1 0

← Newer
1
...
15
16
17
18
19
20
21
22
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2009