- openldap-bugs - openldap.org

Re: (ITS#6320)
by j＠telepaths.org 12 Oct '09

12 Oct '09

Just to clear up any confusion: * Issue is not resolved * Waiting for a response from you guys Please advise. Jeff

1 0

Re: (ITS#6328) Configure OpenLDAP with BO
by quanah＠zimbra.com 12 Oct '09

12 Oct '09

--On Monday, October 12, 2009 9:04 AM +0000 hervelam(a)hotmail.com wrote: > Full_Name: HervE > Version: 2.2.29 Usage questions need to go to openldap-software(a)openldap.org or openldap-technical(a)openldap.org. I would note you are using an ancient unsupported release as well. I'd advise moving to something newer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6328) Configure OpenLDAP with BO
by hervelam＠hotmail.com 12 Oct '09

12 Oct '09

Full_Name: HervE Version: 2.2.29 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.181) I am trying to configure BusinessObjects in order to use OpenLDAP with it. In the LDAP authentification menu in BO, I have to map all the following attributes with the appropriate tags: Mappings of LDAP server attributes Object class: Static Group: Member of static group: Dynamic Group: Dynamic Group Filter: Group description: User object Class: Username: Full name of the user: Email User: User Description: Default LDAP search attributes Default group research attribute: Default user research attribute: Can anyone help me please? Regards, HervE

1 0

Re: (ITS#6320)
by j＠telepaths.org 11 Oct '09

11 Oct '09

OpenLDAP ITS: OK the issue is looking more and more like buggy slapd behavior. I have now narrowed down the issue to an instance where slapd is partially "hung" and will not stop nor restart. This directly correlates to replication breaking because SLAPD is breaking: Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (gidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:46:41 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:48:37 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:49:05 server1 slapd[10771]: daemon: shutdown requested and initiated. Oct 11 18:49:05 server1 slapd[10771]: slapd shutdown: waiting for 0 operations/tasks to finish As you can see, the exact time when this occurs doesn't bring anything interesting to the logs. You can see the repeated string of index warnings (not an issue, just haven't indexed this attribute yet) followed by my attempt to restart slapd when I receive a notification indicating there is a replication discrepancy. I have grepped through all of my logs (dmesg, debug, syslog) for anything related to slapd. What you see above is the more interesting of the hits returned. PLEASE help -- the issue is getting more serious now, and by the evidence I've presented, is looking more and more out of my control. You've seen my config - can anyone think of why this would happen? It seems vaguely like a locking issue .... Thanks Jeff

1 0

Re: (ITS#6320)
by j＠telepaths.org 11 Oct '09

11 Oct '09

> FYI .... > > Before going to sleep last night, I left a persistent connection > open to an LDAP server: > > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > ldap_result: Can't contact LDAP server (-1) <-- > sometime during the night, the connection breaks. > This turned out to be the Kerberos credentials acquired for this test command had expired. Last night, I ran the same command via Simple Bind before going to sleep. The connection is still alive several hours later. This disproves the theory of firewall-induced timeouts for replication that is achieved outside the current local zone. Jeff

1 0

Re: (ITS#6320)
by j＠telepaths.org 10 Oct '09

10 Oct '09

FYI .... Before going to sleep last night, I left a persistent connection open to an LDAP server: SyncInfo Received SyncInfo Received SyncInfo Received SyncInfo Received ldap_result: Can't contact LDAP server (-1) <-- sometime during the night, the connection breaks.

1 0

Re: (ITS#6320)
by j＠telepaths.org 09 Oct '09

09 Oct '09

OK, since my last correspondence, things seemed to be going OK. All changes had been replicated perfectly until last night, I deleted one record, and it only deleted on 4 of 6 of my servers. I removed it manually from one of the other two 'offending' servers. The last one then deleted the record on its own. So it seems as though SyncRepl is highly flaky. I looked into the firewall timeout issue and determined that it is not the cause (if it were, this issue would be happening every 30 minutes (default firewall timeout for the LDAP service)). We're still using the accesslog DB for write-transactions. Jeff

1 0

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

08 Oct '09

A syncrepl-related error also happened in test050. I also can not reproduce easily. test failed - server 1 and server 4 configs differ >>>>> ./scripts/test050-syncrepl-multimaster failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

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

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs