openldap-devel

openldap-devel@openldap.org

1418 discussions

RE24 testing call (2.4.17) round 3
by Quanah Gibson-Mount 02 Jul '09

02 Jul '09

Remaining known issues are now fixed. Please test with updated CVS of RE24. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

ITS and attachments
by Michael Ströder 01 Jul '09

01 Jul '09

HI! When posting an ITS together with testrun data I always put the ITS number in the archive's file name but I don't know the number before submitting the ITS. Therefore I wait until the generated ITS message to be received and then follow up with the URL to the testrun data. Would be much better if attachments (or at least URLs) could added to an issue after submission (like in Bugzilla) to avoid URL references to external resources. Ciao, Michael.

2 1

RE24 testing call (2.4.17) round 2
by Quanah Gibson-Mount 01 Jul '09

01 Jul '09

Please test RE24 and report any issues. All known regressions are now believed fixed. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

7 13

Re: commit: ldap/servers/slapd/overlays ppolicy.c
by Howard Chu 30 Jun '09

30 Jun '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > ppolicy.c 1.125 -> 1.126 > > Log Message: > Fix check_password with {cleartext} passwords As I note in the added comment, the check_password interface kinda sucks here. Instead of making the external module malloc its error message string, we should have passed in a struct berval with a buffer and length(buffer) already set. I'd like to change this for 2.5, it will also simplify ITS#6082. -- -- 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: commit: ldap/servers/slapd connection.c
by Howard Chu 28 Jun '09

28 Jun '09

hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > connection.c 1.440 -> 1.441 > > Log Message: > Fix Debug format in last commit Oops. That was one of my private testing bits, not intended for commit. -- -- 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: RE24 testing call (2.4.17) round 2
by Gavin Henry 28 Jun '09

28 Jun '09

I'm away all this week so will try remotely and report back. Cheers. On 27/06/2009, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Please test RE24 and report any issues. All known regressions are now > believed fixed. Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: commit: ldap/servers/slapd/back-ldap back-ldap.h bind.c
by Howard Chu 22 Jun '09

22 Jun '09

quanah(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldap > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_4 > back-ldap.h 1.88.2.13 -> 1.88.2.14 > bind.c 1.162.2.21 -> 1.162.2.22 > > Log Message: > ITS#6167 This ITS is still Open/Incoming; was this commit really supposed to be released, or is the ITS just not up to date? > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldap/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldap/back-ldap.h > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldap/bind.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

RE24 testing call (2.4.17)
by Quanah Gibson-Mount 18 Jun '09

18 Jun '09

Please test RE24 as we prepare for 2.4.17. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 21

Re: commit: ldap/servers/slapd/overlays pcache.c
by Howard Chu 15 Jun '09

15 Jun '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > pcache.c 1.168 -> 1.169 > > Log Message: > Partially revert 1.32; pcache must allow other callbacks to see its results Regarding the original reason for this change... It's clear that what we really want is for pcache to behave the same in the cached vs uncached case, wrt other overlays/callbacks. So wherever pcache takes control in the call stack for the uncached case, it should do the same in the cached case. What's not clear is how to do that in general. When "response-callback head" has been configured, it should just execute and leave the callback stack intact when answering from cache. When "tail" (the default) is in effect then it probably should bypass the stack. The above commit just leaves the stack intact; I'll fix it up now to depend on the response-callback setting. > * To: OpenLDAP Commit <openldap-commit2devel(a)OpenLDAP.org> > * Subject: Re: commit: ldap/servers/slapd/overlays pcache.c > * From: Pierangelo Masarati <ando(a)sys-net.it> > * Date: Tue, 24 Aug 2004 10:40:00 +0200 > ando(a)OpenLDAP.org wrote: > > > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > > Modified Files: > pcache.c 1.31 -> 1.32 > > > Log Message: > - proxy cache erroneously returns the filtering attributes > and the objectClass right after caching, even if not requested, > while subsequent searches are fine; > > > I think this is a bug; it was also reflected in the test data, which has been > fixed accordingly > > - the response callback needs be apended at the end of the > callback list, otherwise the resulting entries are cached > > > I ran into this issue while developing an overlay that dynamically builds > entries; the raw entry was being cached instead of the completed one, > because pcache adds its callback only when required, while that of my > overlay is stacked by the overlay infrastructure. I think the "natural" > behavior of pcache is to cache the final result that is sent to the user. > I guess there might be applications where this is not true, so I made the > original behavior configurable by an (undocumented) directive. -- -- 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: held locks after exit
by Benoit Donnette 11 Jun '09

11 Jun '09

Well, you've highlighted 4 unreleased locks, a solution quite like using a sledgehammer to crack a nut but predictably efficient would be to backtrace() every lock and unlock so as to match them and to identify which locks haven't been released (but your traces show enough detail to help us focus the watch on specific db4 code). If this can help. > After an otherwise "clean" exit of test058, the smc/db directory showed > the following, despite the fact that there was no more 9196 pid on the > system. Is there any facility in db4 to trace locking? > > I don't think slapd's own debugging would give the level of detail that > would be necessary to find a smoking gun, but if I'm just reading stuff > wrong, I have the testrun directory from this. > > ---------- begin output ---------- > > Default locking region information: > 138 Last allocated locker ID > 0x7fffffff Current maximum unused locker ID > 9 Number of lock modes > 1000 Maximum number of locks possible > 1000 Maximum number of lockers possible > 1000 Maximum number of lock objects possible > 20 Number of lock object partitions > 4 Number of current locks > 12 Maximum number of locks at any one time > 3 Maximum number of locks in any one bucket > 0 Maximum number of locks stolen by for an empty partition > 0 Maximum number of locks stolen for any one partition > 9 Number of current lockers > 15 Maximum number of lockers at any one time > 4 Number of current lock objects > 8 Maximum number of lock objects at any one time > 2 Maximum number of lock objects in any one bucket > 0 Maximum number of objects stolen by for an empty partition > 0 Maximum number of objects stolen for any one partition > 1009 Total number of locks requested > 1005 Total number of locks released > 0 Total number of locks upgraded > 46 Total number of locks downgraded > 4 Lock requests not available due to conflicts, for which we waited > 0 Lock requests not available due to conflicts, for which we did not wait > 0 Number of deadlocks > 0 Lock timeout value > 0 Number of locks that have timed out > 0 Transaction timeout value > 0 Number of transactions that have timed out > 488KB The size of the lock region > 4 The number of partition locks that required waiting (0%) > 4 The maximum number of times any partition lock was waited for (0%) > 0 The number of object queue operations that required waiting (0%) > 1 The number of locker allocations that required waiting (0%) > 0 The number of region locks that required waiting (0%) > 2 Maximum hash bucket length > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Lock Region type > 5 Region ID > __db.005 Region name > 0xfecf0000 Original region address > 0xfecf0000 Region address > 0xfecf00c8 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest > Allocations by power-of-two sizes: > 1KB 3003 > 2KB 0 > 4KB 0 > 8KB 0 > 16KB 2 > 32KB 0 > 64KB 1 > 128KB 0 > 256KB 0 > 512KB 0 > 1024KB 0 > REGION_JOIN_OK Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock region parameters: > 104 Lock region region mutex [0/119 0% 11775/1] > 1031 locker table size > 1031 object table size > 616 obj_off > 63456 locker_off > 0 need_dd > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock conflict matrix: > 0 0 0 0 0 0 0 0 0 > 0 0 1 0 1 0 1 0 1 > 0 1 1 1 1 1 1 1 1 > 0 0 0 0 0 0 0 0 0 > 0 1 1 0 0 0 0 1 1 > 0 0 1 0 0 0 0 0 1 > 0 1 1 0 0 0 0 1 1 > 0 0 1 0 1 0 1 0 0 > 0 1 1 0 1 1 1 0 1 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 85 dd= 0 locks held 1 write locks 0 pid/thread 9196/1 > 85 READ 1 HELD id2entry.bdb handle > 0 > 86 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 87 dd= 0 locks held 1 write locks 0 pid/thread 9196/1 > 87 READ 1 HELD dn2id.bdb handle > 0 > 88 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 89 dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 8a dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 8000013c dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 8000013d dd= 0 locks held 0 write locks 0 pid/thread 9196/1 > 80000145 dd= 0 locks held 2 write locks 2 pid/thread 9196/1 > 80000145 WRITE 1 HELD 0x39548 len: 5 data: 0000000x0100 > 80000145 WRITE 1 HELD id2entry.bdb page 1 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 80000145 WRITE 1 HELD 0x39548 len: 5 data: 0000000x0100 > > 80000145 WRITE 1 HELD id2entry.bdb page 1 > > 85 READ 1 HELD id2entry.bdb handle > 0 > > 87 READ 1 HELD dn2id.bdb handle > 0 > > > >

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel