openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by hyc＠symas.com 10 Apr '08

10 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > - 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. I have the feeling that MUSTBEFREED and MUSTRELEASE should be consolidated into a single flag. be_entry_release_r() should simply call entry_free() if e->e_private is NULL. > + 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. -- -- 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#5451) syncprov_checkpoint deadlock bugfix?
by hyc＠symas.com 10 Apr '08

10 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). > I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. > (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if > and only if rs.sr_entry->e_private != NULL. Which is possibly true with > back-bdb but seems a shaky assumption in general.) That is a requirement, yes. If you implement a backend that has cache/locking constraints on its entries and you don't provide a pointer from the entry back to your cache state, then you're an idiot. That means every time you want to manipulate the cache state for that entry you'll have to do an expensive search for it, instead of simply dereferencing e_private. If you maintain private state for the entry, you point to it with e_private. If e_private is not set, then there is no private state. -- -- 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 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

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