openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

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

10 Apr '08

Aaron Richton wrote: > Ergh, didn't realize there was more past that. > > (dbx) print a->a_vals[0] > a->a_vals[0] = { > bv_len = 28U > bv_val = 0x11925f250 "fixed-address 172.16.143.152" > } > (dbx) print a->a_vals[1] > a->a_vals[1] = { > bv_len = 0 > bv_val = 0x117e9a810 "" > } > (dbx) print a->a_vals[2] > a->a_vals[2] = { > bv_len = 0 > bv_val = (nil) > } > (dbx) print a->a_nvals[0] > a->a_nvals[0] = { > bv_len = 28U > bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" > } > (dbx) print a->a_nvals[1] > a->a_nvals[1] = { > bv_len = 0 > bv_val = (nil) > } > Is this entry still in your database now? Clearly this condition should never happen - if zero-length values are valid for the syntax, then it should have been preserved in the (normalized) a_nvals. If not, then it should not have been in the a_vals in the first place. -- -- 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

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

10 Apr '08

Ergh, didn't realize there was more past that. (dbx) print a->a_vals[0] a->a_vals[0] = { bv_len = 28U bv_val = 0x11925f250 "fixed-address 172.16.143.152" } (dbx) print a->a_vals[1] a->a_vals[1] = { bv_len = 0 bv_val = 0x117e9a810 "" } (dbx) print a->a_vals[2] a->a_vals[2] = { bv_len = 0 bv_val = (nil) } (dbx) print a->a_nvals[0] a->a_nvals[0] = { bv_len = 28U bv_val = 0x11a48ff90 "fixed-address 172.16.143.152" } (dbx) print a->a_nvals[1] a->a_nvals[1] = { bv_len = 0 bv_val = (nil) }

1 0

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

10 Apr '08

Aaron Richton wrote: >> 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. The entry_decode error definitely implies a corruption somewhere. It was looking at a 26 byte value as if it was the name of an attribute. I wonder if slapcat will run cleanly on it now, or if it will also encounter some decode errors. -- -- 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

Re: (ITS#5457) bdb_add() does not always release entries
by hyc＠symas.com 10 Apr '08

10 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p ); >>> (...) >> Releasing entries is somewhat irrelevant, since all locks are released when >> the transaction commits. Note that this function is a no-op in proto-bdb.h. >> All of those statements are just relics from the first entry cache design, >> before we switched to using BDB locks for everything. > > OK. Does that apply to bdb_cache_return_entry_r( bdb, oe,&lock ); > after > bdb_cache_add( bdb, ei, op->ora_e,&nrdn, rlocker,&lock ); > failed TXN_COMMIT( ltid, 0 ); > too? bdb_cache_return_entry_r() is not a no-op. No, that call obviously matters. But I'm not sure that this commit can ever actually fail, or what to do about it if it does. Since all of these write ops use a nested transaction, and there is nothing outstanding in the outer transaction, and the inner transaction has already committed successfully, the only thing that could cause the outer commit to fail would be something like running out of disk for the transaction log. -- -- 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

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

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