openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#4953) test043-delta-syncrepl failed (exit 1): producer and consumer databases differ
by michael＠stroeder.com 10 May '07

10 May '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.125.59) michael@nb2:/usr/src/openldap-HEAD/ldap/tests> ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... 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 entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 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

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 10 May '07

10 May '07

h.b.furuseth(a)usit.uio.no wrote: > OK, I've fixed some of it in HEAD. See comments in the commits for > tpool.c 1.63 and outwards. Quite a lot of changes, will take some time to evaluate the overall impact. > > RE23 has the same problems. Nearly identical code sans the new > semaphore stuff and a few variable names, so fixes should be easy > to import when they've been tested a bit. The semaphore stuff probably needs to be axed/unifdef'd. It is unusable, it would only result in deadlocks, and I think I already removed the slapd code that would have invoked it. > Remaining problems: > > tpool.c breaks if there are multiple pools. The simplest > solution seems to be to remove support for multiple pools. > The problem is thread_keys[]. It is shared between pools, but: slapd only uses a single pool, and that's really the only use case we care about. In fact it makes no sense to support multiple pools, because we have no mechanism to assert scheduling priorities of one pool over another. > Other thread_keys[] strangeness: > > - setkey does not free the old data with ltk_free. Possibly that's > intentional, but if so that requires weird code elsewhere. Yes, that's intentional. ltk_free is only intended for cleanup if a key is still set by the time a thread exits. All of the keys we set are live for the entire life of a thread, they don't get re-assigned. > - maybe related to how getkey can return the ltk_free function - which > seems crazy since a caller who uses it must then explicitly reset the > key afterwards (or better, before), to be sure purgekey doesn't > see the data and free it again. Nothing actually depends on returning the ltk_free function, that was just included for completeness' sake. > Other notes: > > - I've inserted new, possibly too aggressive, waits for ltp_pause in > pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative > than splitting the ltp_pause state might be to remove the requirement > that purgekey() can only be used by a paused thread. (Could loop > until the key is _really_ gone instead, or something.) Will look at this later. > > - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), > which uses thread_keys[]. If one thread does that when another thread > has paused the pool, that can break since thread_keys[] is reserved > for ldap_pvt_thread_pool_purgekey() during pauses. Since there is only one thread pool in use, it is impossible for another thread to be active. > - ltp_pending_count includes threads sleeping in pool_pause() - should > it? In effect, pool_pause() temporarily reduces ltp_max_pending. I don't see why any special consideration is needed here. Nothing else in the thread pool is going to move while a pause is in effect. > - In ldap_pvt_thread_pool_submit(): > > This comment: > /* there is another open thread, so this > * context will be handled eventually. > * continue on and signal that the context > * is waiting. > */ > is wrong if the previous if (pool->ltp_open_count == 0) was > taken but the no thread was found inside that. The comment may be incomplete... > Also if ctx is invalid (another thread handled it) and a new > pending request has gotten the now-unused ctx, then the > 'if (pool->ltp_open_count == 0)' code will free that new > pending request instead of the old one. Most likely this is due to unlocking and relocking the mutex around the semaphore code. Axe that, remove the gratuitous unlock/relock, and then that problem goes away. > - Note, I haven't looked at the new semaphore stuff yet. > > Will get back to this later, but could use review so far. In particular > I'd like to know if we'll keep or kill multi-pool support. Thus far we've only had to worry about a single pool. If anyone can come up with a reason to need multiple pools, I guess we need to hear it. Given the lack of scheduling control, I don't see how it would be of any benefit. At the same time, I don't see a compelling reason to perturb the code at the moment. -- -- 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

OK, I've fixed some of it in HEAD. See comments in the commits for tpool.c 1.63 and outwards. RE23 has the same problems. Nearly identical code sans the new semaphore stuff and a few variable names, so fixes should be easy to import when they've been tested a bit. Remaining problems: tpool.c breaks if there are multiple pools. The simplest solution seems to be to remove support for multiple pools. The problem is thread_keys[]. It is shared between pools, but: - ldap_pvt_thread_pool_purgekey() needs _all_ pools to be paused, but ldap_pvt_thread_pool_pause() only pauses one pool. If we keep multi-pool support, maybe it only should destroy keys from the current pool? - ltp_max_count (max #threads) is pool-specific, but is used to protect from array bounds violation on thread_keys[LDAP_MAXTHR]. (New simple code from me, previously there was no limit.) - This '#if 0'ed comment is also wrong with multiple pools: /* start up one thread, just so there is one. no need to * lock the mutex right now, since no threads are running. */ Time to remove the whole #if 0? Other thread_keys[] strangeness: - setkey does not free the old data with ltk_free. Possibly that's intentional, but if so that requires weird code elsewhere. - maybe related to how getkey can return the ltk_free function - which seems crazy since a caller who uses it must then explicitly reset the key afterwards (or better, before), to be sure purgekey doesn't see the data and free it again. Other notes: - I've inserted new, possibly too aggressive, waits for ltp_pause in pool_wrapper. See the tpool.c 1.65 comment. Yet another alternative than splitting the ltp_pause state might be to remove the requirement that purgekey() can only be used by a paused thread. (Could loop until the key is _really_ gone instead, or something.) - tpool.c uses LDAP_FREE(), can call ldap_pvt_thread_pool_context(), which uses thread_keys[]. If one thread does that when another thread has paused the pool, that can break since thread_keys[] is reserved for ldap_pvt_thread_pool_purgekey() during pauses. Not sure if that can happen, haven't checked. If LDAP_MALLOC/LDAP_CALLOC also can do call pool_context(), we do have problem in pool_submit(). One fix is to use malloc/calloc/free instead. Another, in the case of LDAP_FREE(ctx) in pool_submit, is to put the ctx on the free list instead. - ltp_pending_count includes threads sleeping in pool_pause() - should it? In effect, pool_pause() temporarily reduces ltp_max_pending. - In ldap_pvt_thread_pool_submit(): This comment: /* there is another open thread, so this * context will be handled eventually. * continue on and signal that the context * is waiting. */ is wrong if the previous if (pool->ltp_open_count == 0) was taken but the no thread was found inside that. Also if ctx is invalid (another thread handled it) and a new pending request has gotten the now-unused ctx, then the 'if (pool->ltp_open_count == 0)' code will free that new pending request instead of the old one. One fix is to add an is_pending flag=1 in submit() and int *ltc_pendingp; in ldap_int_thread_ctx_t. In submit, if need_thread, set ltc_pendingp = &is_pending. In if(pool->ltp_open_count == 0) check is_pending instead of searching for ctx. Elsewhere set *ltc_pendingp = 0 and/or ltc_pendingp = NULL when appropriate. - Note, I haven't looked at the new semaphore stuff yet. Will get back to this later, but could use review so far. In particular I'd like to know if we'll keep or kill multi-pool support. -- Regards, Hallvard

1 0

(ITS#4952) null CSN due to CSN length mismatch in updateCookie
by donn＠u.washington.edu 09 May '07

09 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) syncrepl_updateCookie finds CSN values in syncCookie and si->si_cookieState. Numerically, the syncCookie CSN is lesser, but it compares greater because it's longer: syncCookie->ctxcsn: 20070508130333Z#000000#00#000000 si->si_cookieState->cs_vals[0]: 20070507215402.502403Z#000000#000#000000 Eventually slap_queue_csn() gets a null CSN, and slapd aborts. I am pretty sure the former explains the latter. The only thing that doesn't fit is that gdb reports "j" == 20936000, where I expect 0, but I think everything else adds up - numcsns is 1, cs_num is 1, the two sids are the same (0). Evidently this format difference is entryCSN vs. contextCSN. The unusual order may be due to entries modified in the master with explicit entryCSN values. I guess that's not supported, but it seems to have exposed a bug here - I assume you want a comparison between dates, not format lengths. To reproduce (I'm guessing): modify master directory with explicit entryCSN values that are later than its contextCSN.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

Actually, tpool.c is quite buggy. I'm fixing some of them, and will summarize the rest later. -- Regards, Hallvard

1 0

Re: (ITS#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

I wrote: > That said, it's indeed a reasonable cleanup. I'll do that and some > others shortly. Fixed in the cvs HEAD version. There are a few cases left though - in particular, do anyone know if #if DOS/MACOS/HAVE_WINSOCK can be replaced with #ifdef? I'm not touching them without word from someone who knows OpenLDAP on these platforms. Besides, I still don't know if the "issues" you refer to are just compiler warnings, or errors - or if the one macro you reported was a special case. So while allowing -Wundef to catch macro typos is worthwhile, I likely won't do anything more unless I hear a reason to. And I'd like to know what Plan 9 C says about this program: > BTW, will 9 C accept this (when you do not define FOO/BAR)? What > error/warning messages, if any? > > #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ > int main() { return 2; } > #elif BAR > int main() { return 1; } > #else > int main() { return 0; } > #endif -- Regards, Hallvard

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

hyc(a)symas.com writes: > This seems to be a known limitation, see the FIXME in slapd/compare.c, > near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem > for back-ldif, which does not provide its own compare entry point. Looks like a bug to me, and that the correct fix is be to delete that code and let the current back-ldif return an error. Maybe it could be split out to a separate function which backends can set be_compare to if they have a be_attribute(), or something like that? > As for back-ldbm, there is a missing referral_rewrite call in > back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, > but you're welcome to fix it if you wish. I might, though actually I'm more concerned with failed tests than fixing ldbm at the moment:-) Will look later. However: > Just have a look at back-bdb/referral.c for the correct code. There is no correct code as yet, note the bogus logging I mentioned. -- Regards, Hallvard

1 0

(ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 09 May '07

09 May '07

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: https://www.nbcs.rutgers.edu/~richton/richton-20070508-radius.patch Submission from: (NULL) (68.196.250.105) Please find at this address a patch against the RADIUS contrib module. This patch addresses two issues: * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. * config_filename could be passed to rad_config without initialization (when accepting the default). I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 08 May '07

08 May '07

On Tue, May 08, 2007 at 08:42:24PM +0200, Pierangelo Masarati wrote: > ahasenack(a)terra.com.br wrote: > > > The monitor backend attributes and object classes, when loaded, should also be > > exported in the subschema entries at the server. > > > > I know of one ldap client that breaks because of this: luma. It says it can't > > display the cn=monitor entries because it doesn't know the object classes or > > attributes. I guess it uses this info to determine how to show each entry. > > The schema is not exposed since it's considered experimental. To expose > it, you need to #define LDAP_DEVEL. It doesn't see a good idea for me to define LDAP_DEVEL just to get this schema published: probably many other things in openldap would change.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ando＠sys-net.it 08 May '07

08 May '07

ahasenack(a)terra.com.br wrote: > The monitor backend attributes and object classes, when loaded, should also be > exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it can't > display the cn=monitor entries because it doesn't know the object classes or > attributes. I guess it uses this info to determine how to show each entry. The schema is not exposed since it's considered experimental. To expose it, you need to #define LDAP_DEVEL. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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