openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 26 Feb '08

26 Feb '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > One hdb backend on one slave died ~21:58 yesterday... > > current thread: t@5 > [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in > "config.c" > [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > (dbx) where > current thread: t@16 > [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at > 0xffffffff7f0a741c > [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, > 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c > [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at > 0xffffffff7e0108e8 > =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in > "os_sleep.c" > [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = > DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" > [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" > [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1389 in "txn.c" > [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, > flags = 0), line 1288 in "txn.c" > [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in > "delete.c" > [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), > modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, > syncCookie_req = 0xffffffff46fff360, syncCSN = > 0xffffffff46fff390), line 2006 in "syncrepl.c" > [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in > "syncrepl.c" > [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in > "syncrepl.c" > [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" > > > I can't get db_stat to join the environment. If there's anything else that can > be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, > I'm off to rm/slapadd... > > "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of > the changes (to my eye) looked locking related. Unfortunately no, nothing familiar here. There's nothing in the BDB documentation that says two threads are not allowed to call txn_checkpoint concurrently, but I suppose it may be excessive to make multiple calls in rapid succession. One thing that I've started doing recently in my configs is to skip the #bytes option (leave it zero), so that only time-based checkpoints occur. Since they're done in a dedicated task, only one thread at a time can trigger a checkpoint. -- -- 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#5391) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Feb '08

26 Feb '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) One hdb backend on one slave died ~21:58 yesterday... current thread: t@5 [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in "config.c" [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" (dbx) where current thread: t@16 [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at 0xffffffff7f0a741c [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0, 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at 0xffffffff7e0108e8 =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in "os_sleep.c" [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op = DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c" [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c" [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1389 in "txn.c" [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U, flags = 0), line 1288 in "txn.c" [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in "delete.c" [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil), modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0, syncCookie_req = 0xffffffff46fff360, syncCSN = 0xffffffff46fff390), line 2006 in "syncrepl.c" [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in "syncrepl.c" [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in "syncrepl.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c" I can't get db_stat to join the environment. If there's anything else that can be gleaned from slapd itself, I'd be glad to poke around the core; otherwise, I'm off to rm/slapadd... "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of the changes (to my eye) looked locking related.

1 0

Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > Emmanuel Lecharny wrote: >> Howard Chu wrote: >>> There's no bug here, and the schema parser isn't causing your problem. >>> As documented in slapd.conf(5), directives must form a single logical >>> line. Lines that are split must be continued by a leading space >>> character. > >> Assuming this is not a bug, this is still really painfull... It would be >> much better to consider that the AttributeType, being parenthesed, can >> be scanned without taking into account the leading white space, until >> the closing ')'. > > The config file parser breaks the input into lines before scanning to > see what keywords are actually on those lines. The syntax of the > config file has been documented to behave this way for over 10 years. > Nobody else has cared to change it until now... FYI, before having RTFM, I thought that the only possible "include" I can use was for schema file. It made sense to me then that OpenLDAP was using a specific parser for schema, but I was wrong. It seems that I have missed the part of the doc where this 'first space requirement' is mentionned... We were lucky enough in ADS to be able to use a contextfull parser for those schema file (we support the same format), so we were able to relax this constraint. Supposing that ADS behavior is to be expected by OpenLDAP is obviously a mistake ... I wish I have some time to provide some patch for OpenLDAP to relax such a constraint, but, eh, if I say so, that would be a damn lie ! > > Of course, all of that is going to be phased out as we move to pure > LDIF in the future. (Which again, requires a leading space character > for line continuations. And again, is a well documented feature of the > format.) Yeah, the problem will remain, but at least, there is a RFC for idiot like me who don't do their homeworks... The *big* advantage to have LDIF formatted schemas is that you won't have anymore to care about ordering the elements inside attributeTypes and objectClasses... Btw, we do have some LDIF format for Shcema, and I was wondering if it won't be a good idea to try to define a common format ? I would really appreciate if a LDIF schema file could be directly injected in both ADS and OpenLDAP ! Thanks. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

Emmanuel Lecharny wrote: > Howard Chu wrote: >> There's no bug here, and the schema parser isn't causing your problem. >> As documented in slapd.conf(5), directives must form a single logical >> line. Lines that are split must be continued by a leading space >> character. > Assuming this is not a bug, this is still really painfull... It would be > much better to consider that the AttributeType, being parenthesed, can > be scanned without taking into account the leading white space, until > the closing ')'. The config file parser breaks the input into lines before scanning to see what keywords are actually on those lines. The syntax of the config file has been documented to behave this way for over 10 years. Nobody else has cared to change it until now... Of course, all of that is going to be phased out as we move to pure LDIF in the future. (Which again, requires a leading space character for line continuations. And again, is a well documented feature of the format.) > That being said, as soon as I have fixed the schema file, I'm not > suffering anymore. I was just thinking about the poor other users ;) > > Thanks Howard ! You're welcome ;) -- -- 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#5390) Error while parsing a schema
by elecharny＠gmail.com 26 Feb '08

26 Feb '08

Howard Chu wrote: > There's no bug here, and the schema parser isn't causing your problem. > As documented in slapd.conf(5), directives must form a single logical > line. Lines that are split must be continued by a leading space > character. Assuming this is not a bug, this is still really painfull... It would be much better to consider that the AttributeType, being parenthesed, can be scanned without taking into account the leading white space, until the closing ')'. That being said, as soon as I have fixed the schema file, I'm not suffering anymore. I was just thinking about the poor other users ;) Thanks Howard ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

1 0

Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com 26 Feb '08

26 Feb '08

There's no bug here, and the schema parser isn't causing your problem. As documented in slapd.conf(5), directives must form a single logical line. Lines that are split must be continued by a leading space character. elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.39 (stable) > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.245.116.110) > > > Trying to load a schema, I got an error because the schema parser is expecting a > WSP before the closing parenthese. Here is the attributeType : > > attributetype ( 1.3.6.1.4.1.30267.0.1 > NAME 'ApplicationName' > SUP name > EQUALITY caseIgnoreMatch > ORDERING caseIgnoreOrderingMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE > ) > ^ > | > +--- note that there is no space here. > > If I add a spece before the ')', the schema is parsed correctly. > > This is breaking RFC 4512 : This has nothing to do with RFC 4512. -- -- 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#5390) Error while parsing a schema
by elecharny＠apache.org 26 Feb '08

26 Feb '08

Full_Name: Emmanuel Lecharny Version: 2.3.39 (stable) OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.245.116.110) Trying to load a schema, I got an error because the schema parser is expecting a WSP before the closing parenthese. Here is the attributeType : attributetype ( 1.3.6.1.4.1.30267.0.1 NAME 'ApplicationName' SUP name EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ^ | +--- note that there is no space here. If I add a spece before the ')', the schema is parsed correctly. This is breaking RFC 4512 : WSP = 0*SPACE ; zero or more " " AttributeTypeDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oid ] ; supertype [ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SINGLE-VALUE" ] ; single-value [ SP "COLLECTIVE" ] ; collective [ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "USAGE" SP usage ] ; usage extensions WSP RPAREN ; extensions The main problem with this kind of parsing error is that some users may spent _hours_ finding out what's going on... I just spoilt one full hour myself :/ Also the logs are not really self-explanatory... : ... AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other ; AttributeType [ "EQUALITY" woid ] ; Matching Rule name [ "ORDERING" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "USAGE" whsp AttributeUsage ]; default userApplications ; userApplications ; directoryOperation ; distributedOperation ; dSAOperation whsp ")" /opt/ldap/openldap/etc/openldap/schema/sofinco.schema: line 13: <attributetype> handler exited with 1! ...

1 0

(ITS#5389) Contribution: JLDAP support for password policy response control
by t2tre＠skyblue.eu.com 25 Feb '08

25 Feb '08

Full_Name: Raymond Edah Version: JLDAP CVS HEAD OS: Windows URL: http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz Submission from: (NULL) (81.3.106.202) Hi, I have written a class for handling the password policy response control as described in draft-behera-ldap-password-policy-09.txt. I would like to contribute it to the OpenLDAP project. A copy of the code can be found at http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz. Regards, Ray Edah

1 0

(ITS#5388) NULL pointer dereference
by dhen42＠yahoo.co.uk 25 Feb '08

25 Feb '08

Full_Name: Dennis Henriksen Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.10) In server/slapd/oc.c(oc_next) suffers from a potential NULL pointer dereference in the statement '*oc = LDAP_STAILQ_NEXT(*oc,soc_next);'. Perhaps this should read (if *oc != NULL) *oc = LDAP_STAILQ_NEXT(*oc,soc_next);'

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 25 Feb '08

25 Feb '08

h.b.furuseth(a)usit.uio.no a écrit : > jclarke(a)linagora.com writes: >> When slapcat is writing it's output to disk, it ignores any errors >> (with slapcat -l output_file or slapcat > output_file). If an error is >> encountered, such as "No space left on device", slapcat then exits >> normally with a return code of 0. > > Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() > have no way to return error. At best they can set an "error" flag > in the internal database structure, and API calls which are able > to return errors can react to that. Hmmm. I may have misunderstood, but it seems this concerns internal errors, whereas I was referring to the output (writing the data to stdout or to a file) errors. The patch I attached addresses this issue, is there any chance of seeing it included in OpenLDAP, or does it need some more work? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

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