openldap-bugs April 2008

openldap-bugs@openldap.org

45 participants
192 discussions

Re: (ITS#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 10 Apr '08

10 Apr '08

> Definitely an oddball. Can you print i, j, and a->a_vals[0] thru > a->a_vals[i], > plus a->a_nvals[0] thru a->a_nvals[j]. Just got back to my desk and started looking at this. So when the two slaves that threw this were restarted, they went into an infinite loop trying to replicate the entry that killed them: <= entry_decode: slap_str2undef_ad(^Zethernet 01:aa:aa:aa:aa:a1): AttributeDescription contains inappropriate characters null_callback: error code 0x50 syncrepl_entry: rid 110 be_add (80) syncrepl_entry: rid 110 be_add failed (80) do_syncrepl: rid 110 retrying and retrying, and retrying, and retrying...hence my thought that the database was hosed...UNTIL... Apparently the entry was DEL'd a few hours later. I've now got perfect sync from the master to the assert'd slaves. There's nothing secret in this particular backend; it's DHCP backing store, so I can give you full values. Both slaves died with an identical: i = 2 j = 1 *a->a_vals = { bv_len = 28U bv_val = 0x11925f250 "fixed-address 172.16.143.152" } *a->a_nvals = { bv_len = 28U bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" }

1 0

Re: (ITS#5459) threw assertion in attr_dup
by hyc＠symas.com 10 Apr '08

10 Apr '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.41 > OS: Solaris 9 > URL: > Submission from: (NULL) (68.192.238.168) > Crazy part is that I hit this on two slaves during the same replication cycle > ... yet four slaves DIDN'T crash during said replication set. I think that > database is hosed on those two slaves; I'll check more thoroughly tomorrow (I'm > off site today). Provider is 2.3.39, so perhaps "it fed 2.3.41 garbage" -- but > still, 2.3.41 should be able to gracefully handle it? Or maybe an assert() is a > graceful handler, but I don't know about that, it kills my slave in the process? Definitely an oddball. Can you print i, j, and a->a_vals[0] thru a->a_vals[i], plus a->a_nvals[0] thru a->a_nvals[j]. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5461) rs->sr_tag/sr_msgid uninitialized at abandon
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slap_send_ldap_result() does not initialize rs->sr_tag and rs->sr_msgid if rs->sr_err == SLAPD_ABANDON || op->o_abandon. It does call send_ldap_response() which calls slap_cleanup_play(). Some cleanup handlers dispatch on rs->sr_tag. If this is deliberate, it's a design bug: Any cleanup callbacks that depend on this suffer at least a race condition, since o_abandon could get set just after slap_send_ldap_result checks for abandon. The code is from slapd/result.c rev 1.252. The fix should be to first check that the cleanup callbacks handle abandon properly, then always initialize these SlapResponse fields.

1 0

Re: (ITS#5458) whitespace parsing in schema files
by mf＠14v.de 10 Apr '08

10 Apr '08

--On Donnerstag, April 10, 2008 11:29:13 +0200 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > Not a bug. The 'attributetype' format is contained inside the > slapd.conf format. The slapd.conf format is that each directive is > written in one conceptual line: one line plus any additional slapd.conf > continuation lines - i.e. lines which start with whitespace. Ok, thanks for replying, bug can be closed (if it isn't already). That was my fault, I had simply assumed from looking at the other schema files that schema definitions were in some context-free grammar like C or Pascal. The log message containing input from an earlier schema include is still somewhat confusing. Best regards Matthias Ferdinand

1 0

Re: (ITS#5458) whitespace parsing in schema files
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

mf(a)14v.de writes: > attributetype ( 1.3.6.1.4.1.22558.2.1.1 > NAME 'o4vdescription' > DESC 'RFC2256: descriptive information' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} > ) > > If I leave out the blank preceding the closing paranthesis, so that > there is just the newline between the "{1024}" and the ")", slapd > refuses to start Not a bug. The 'attributetype' format is contained inside the slapd.conf format. The slapd.conf format is that each directive is written in one conceptual line: one line plus any additional slapd.conf continuation lines - i.e. lines which start with whitespace. Though if the documentation is unclear on this point, feel free to suggest how to improve it. -- Hallvard

1 0

(ITS#5460) unresolved symbol
by st-wong＠cuhk.edu.hk 10 Apr '08

10 Apr '08

Full_Name: ST Wong Version: 2.4.8 OS: CentOS 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.189.29.184) Got error when compiling Openldap 2.4.8 with BerkeleyDB 4.6: ---------------------- cut here ----------------------- ... checking for db.h... yes checking for Berkeley DB major version... 4 checking for Berkeley DB minor version... 3 checking for Berkeley DB link (-ldb-4.3)... (cached) no checking for Berkeley DB link (-ldb43)... no checking for Berkeley DB link (-ldb-43)... no checking for Berkeley DB link (-ldb-4-3)... no checking for Berkeley DB link (-ldb-4)... no checking for Berkeley DB link (-ldb4)... no checking for Berkeley DB link (-ldb)... yes checking for Berkeley DB version match... yes checking for Berkeley DB thread support... yes checking Berkeley DB version for BDB/HDB backends... no configure: error: BDB/HDB: BerkeleyDB version incompatible ---------------------- cut here ----------------------- In config.log: ---------------------- cut here ----------------------- configure:17625: checking for resolver link (default) configure:17691: cc -o conftest -g -O2 -I/usr/local/BerkeleyDB.4.6/include -L/usr/local/BerkeleyDB.4.6/lib conftest.c >&5 /tmp/ccczbyKW.o: In function `main': /usr/local/src/openldap-2.4.8/conftest.c:113: undefined reference to `__res_query' /usr/local/src/openldap-2.4.8/conftest.c:132: undefined reference to `__dn_expand' collect2: ld returned 1 exit status ---------------------- cut here ----------------------- Have to add "-lresolv" to LDFLAGS in order to resolve the problem. I suppose configure will add all libraries required. Thanks a lot.

1 0

(ITS#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 09 Apr '08

09 Apr '08

Full_Name: Aaron Richton Version: 2.3.41 OS: Solaris 9 URL: Submission from: (NULL) (68.192.238.168) (dbx) where current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff457fe390, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x30, 0x0, 0x30, 0x7efefeff, 0x81010100, 0xff0000), at 0xffffffff7f03e688 [4] __assert(0x10023d488, 0x10023d490, 0x8d, 0x1, 0xffffffff457fe758, 0x11b369c59), at 0xffffffff7f03e98c =>[5] attr_dup(a = 0x1174b0470), line 141 in "attr.c" [6] attrs_dup(a = 0x1174b0470), line 166 in "attr.c" [7] hdb_modify_internal(op = 0xffffffff457ff618, tid = 0x11b369b70, modlist = 0x118ea8bd0, e = 0xffffffff457feab8, text = 0xffffffff457fefd8, textbuf = 0xffffffff457feb4c "^X\xea\x8b\xd0", textlen = 256U), line 55 in "modify.c" [8] hdb_modify(op = 0xffffffff457ff618, rs = 0xffffffff457fefb8), line 480 in "modify.c" [9] syncrepl_entry(si = 0x1004b5050, op = 0xffffffff457ff618, entry = 0x118d17870, modlist = 0xffffffff457ff328, syncstate = 2, syncUUID = 0xffffffff457ff3c0, syncCookie_req = 0xffffffff457ff360, syncCSN = 0xffffffff457ff390), line 1987 in "syncrepl.c" [10] do_syncrep2(op = 0xffffffff457ff618, si = 0x1004b5050), line 735 in "syncrepl.c" [11] do_syncrepl(ctx = 0xffffffff457ffc30, arg = 0x1004b5230), line 1095 in "syncrepl.c" [12] ldap_int_thread_pool_wrapper(xpool = 0x10041e700), line 478 in "tpool.c" (dbx) list 130,150 130 131 if ( a->a_nvals != a->a_vals ) { 132 int j; 133 134 tmp->a_nvals = ch_malloc( (i + 1) * sizeof(struct berval) ); 135 for ( j = 0; !BER_BVISNULL( &a->a_nvals[j] ); j++ ) { 136 assert( j < i ); 137 ber_dupbv( &tmp->a_nvals[j], &a->a_nvals[j] ); 138 if ( BER_BVISNULL( &tmp->a_nvals[j] ) ) break; 139 /* FIXME: error? */ 140 } 141 assert( j == i ); 142 BER_BVZERO( &tmp->a_nvals[j] ); 143 144 } else { 145 tmp->a_nvals = tmp->a_vals; 146 } 147 148 } else { 149 tmp->a_vals = NULL; 150 tmp->a_nvals = NULL; Crazy part is that I hit this on two slaves during the same replication cycle ... yet four slaves DIDN'T crash during said replication set. I think that database is hosed on those two slaves; I'll check more thoroughly tomorrow (I'm off site today). Provider is 2.3.39, so perhaps "it fed 2.3.41 garbage" -- but still, 2.3.41 should be able to gracefully handle it? Or maybe an assert() is a graceful handler, but I don't know about that, it kills my slave in the process?

1 0

(ITS#5458)
by mf＠14v.de 09 Apr '08

09 Apr '08

Looks like newline does not count as whitespace. Regards Matthias

1 0

(ITS#5458) whitespace parsing in schema files
by mf＠14v.de 09 Apr '08

09 Apr '08

Full_Name: Matthias Ferdinand Version: 2.4.8 OS: Linux/SuSE10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.102.180.118) Platform: SuSE Linux 10.0 OpenLDAP 2.4.8 from pkgsrc (http://www.netbsd.org/docs/pkgsrc/) gcc-4.2.1 (also with OpenLDAP 2.4.7 from Debian Testing) I tried the following simple attribute definition (located at /opt/pkgsrc/etc/openldap/schema/test2.schema): attributetype ( 1.3.6.1.4.1.22558.2.1.1 NAME 'o4vdescription' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) If I leave out the blank preceding the closing paranthesis, so that there is just the newline between the "{1024}" and the ")", slapd refuses to start with some syntax error: AttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType ... and at loglevel 64 some strange syslog entries: Apr 10 00:45:08 vestatest slapd[25297]: line 6 (attributetype ( 1.3.6.1.4.1.22558.2.1.1 NAME 'o4vdescription' DESC 'RFC2256: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}) Apr 10 00:45:08 vestatest slapd[25297]: /opt/pkgsrc/etc/openldap/schema/test2.schema: line 6 attributetype: Missing closing parenthesis before amavisBannedFilesLover $ amavisBypassBannedChecks $ amavisBadHeaderLover $ amavisBypassHeaderChecks $ amavisSpamTagLevel $ amavisSpamTag2Level $ amavisSpamKillLevel $ amavisWhiteli Apr 10 00:45:08 vestatest slapd[25297]: /opt/pkgsrc/etc/openldap/slapd.conf: line 13: <include> handler exited with 1! (the amavis entries are from a schema included just before this one) Looks like the parser reads the attribute definition correctly, but is confused afterwards. Regards Matthias

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Apr '08

09 Apr '08

Below I'll summarize SlapReply.sr_flags as I now understand it after un-confusing myself a little, since this ITS is getting rather long. Mostly about how code which receives a filled SlapReply should use it, which I presume is primarily overlays, slap_callbacks, maybe back-relay. About discussion so far: The sr_flags are inconsistent about when which ones may or must be obeyed. E.g. REP_ENTRY_MUST<RELEASE/BEFREED> does not mean the entry will be released/freed, but REP_<MATCHED/REF> does in some functions. This needs to be normalized. We can state that overlays with a bi_entry_release_rw function must keep track of which module should release which entry, like glue does. At least for now. Never mind my worries about which overlay/backend should release an REP_ENTRY_MUSTRELEASE'd sr_entry. That doesn't matter with current OpenLDAP code. As far as I can see glue is the only overlay with a release function, and glue can dispatch on the entry DN. rs.sr_ref bugs, fixing now: - slap_send_ldap_result() forgets to free rs->sr_ref if it does not call send_ldap_response(). - send_ldap_response() can return with sr_ref set to a freed value. I'll make it return with sr_ref to NULL if REP_REF_MUSTBEFREED. ando(a)sys-net.it writes: > Similarly, the existence of REP_ENTRY_MUSTBEFREED is not totally clear: Looked a bit at cvs logs... Since you are the one who introduced MUSTBEFREED and MODIFIABLE (slap.h 1.503 for rwm) I think we can take it the intent of REP_ENTRY_MUSTBEFREED is indeed unclear/forgotten:-) Anyway, I think I've gotten the flags straight now: * REP_<ENTRY, MATCHED, REF>_MUST<RELEASE, BEFREED>: Overlays/callbacks may modify the rs->sr_<entry, text, ref> pointers. If they do, they must release/free the old value if and only if the corresponding MUST<RELEASE/BEFREED> flag is set. They should (re)set the relevant flags to describe the new value. Many overlays don't, or not thoroughly enough. - REP_<MATCHED, REF>_MUSTBEFREED: Callers setting these can depend on send_ldap_response() to free sr_<matched, ref>. That is, "send response/disconnect" calls. These flags do apparently not apply and should not be set when sending an entry or search continuation reference. Dunno why not REP_REF_MUSTBEFREED when sending continuation references. - REP_ENTRY_MUSTRELEASE and REP_ENTRY_MUSTBEFREED: Callers that set these flags when sending an entry, *allow* the callee to release/free rs->sr_entry. Callers cannot depend on it being release/freed, but some do anyway. It should simplify things to make the send functions always obey this flag, but I'm not sure how much cleanup that requires. There is partial code for that in slap_send_search_entry(), along with a FIXME note. Free MUSTBEFREED-entries with entry_free(), and MUSTRELEASE-entries with be_entry_release_r(). There is no "use be_entry_release_w()" flag, but no OpenLDAP code sends write-locked entries anyway. + REP_ENTRY_MUSTRELEASE: Created for ITS#3671 to ensure that network hangs don't delay cache entry unlocks: Modules should release their cache entry locks before sending anything. They can't do that with cached entries they send in rs->sr_entry, so instead they should set REP_ENTRY_MUSTRELEASE. Conversely, anything which does network I/O (and other potentially slooow ops I guess) should first obey this flag. Several overlays don't obey, nor some other code for sending an entry when it decides to send an error response instead. * REP_ENTRY_MODIFIABLE: Overlays and callbacks may modify the entry which rs->sr_entry points at if this flag is set. If they want to modify an incoming sr_entry when REP_ENTRY_MODIFIABLE is not set, they can use entry_dup(), release or free the old entry if sr_flags says so, put the new entry in sr_entry, and maybe set REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED. Thus code which creates a temporary Entry struct and sends it as rs->sr_entry, should set REP_ENTRY_MODIFIABLE if the entry is of no further interest to it (and it has set no pointers into it, e.g. rs->sr_matched). That allows overlays that wish to modify the entry being sent, to use this entry instead of copying it. * REP_NO_<OPERATIONALS, ENTRYDN, SUBSCHEMA>: Set by the chain overlay to "tell the frontend not to add generated operational attributes". Only backend.c reacts to these flags. Dunno if overlays should reset these flags when replacing sr_entry with a "private" entry (with another DN) rather than a dup of the current one, or something. Some overlays set sr_flags to fresh values while others only update some bits in sr_flags, so the effect is likely somewhat ad-hoc. Leaving that worry to someone else. I've been fiddling with some functions to generalize this, but they seem to need a lot of flags or variants for different modes... Should maybe just commit some draft variants with warnings that they may change, and clean up later. After my changes don't cause slapd to crash, anyway:-) -- Hallvard

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
20
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 April 2008