openldap-devel

openldap-devel@openldap.org

2 participants
1419 discussions

RE24 testing call #3 (OL 2.4.24)
by Quanah Gibson-Mount 17 Jan '11

17 Jan '11

Fixes to the dreaded solaris hang with back-monitor included. Please test. :) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

7 12

Re: commit: ldap/servers/slapd/overlays rwm.c
by Hallvard B Furuseth 17 Jan '11

17 Jan '11

ando(a)OpenLDAP.org writes: > rwm.c 1.138 -> 1.139 > make sure rwm_response returns SLAP_CB_CONTINUE (ITS#6792, as indicated by Hallvard) Why the new 'default: rwm_matched( op, rs );'? So you can rewrite matchedDN in responses to Abandon and Unbind? :-) -- Hallvard

1 0

librewrite & co vs. logging & ldap-int.h
by Hallvard B Furuseth 13 Jan '11

13 Jan '11

The ITS#6625 patch causes preprocessor warnings about conflicts with ldap-int.h, so I'm looking again at old ITS#5421 to kill off #include "...libldap/ldap-int.h" These occur in librewrite, rwm, back-ldap and back-meta. The #include is for two things: Expose struct ldapmsg & LDAP_FREE, the need of which I've just removed in HEAD, and set up libldap logging. I expect the slapd components just as well can drop the #include and use slapd logging? back-*/search.c then need lber-int.h instead. librewrite still needs the #define ldap_debug in ldap-int.h. Instead we could either: (1) use liblber logging in librewrite, (2) or throw the code LDAP_INT_IN_KERNEL .. #endif /* LDAP_DEBUG */ out of ldap-int.h to a separate file, either include/ldap_log.h or something like libldap/ldap-int-log.h. This file would not expose structs with different definitions depending on LDAP_R_COMPILE & co. Since the file when not LDAP_INT_IN_KERNEL does need to refer ldap_debug to ldap_int_global_options.ldo_debug, that can be done with: /* This struct starts with the same members as ldapoptions */ struct ldapoptions_prefix { short ldo_valid; int ldo_debug; }; #define ldap_debug \ (*(int *) ((char *) &ldap_int_global_options \ + offsetof(struct ldapoptions_prefix, ldo_debug))) struct ldapoptions; LDAP_V ( struct ldapoptions ) ldap_int_global_options; Opinions? Put it in ldap-int.h, or ldap_log.h? Maybe the latter only if #defined LDAP_LIBRARY_LOGGING (defined by the user)? -- Hallvard

2 1

RE24 testing call #1 (OL 2.4.24)
by Quanah Gibson-Mount 13 Jan '11

13 Jan '11

Please test RE24 heavily. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

11 22

Re: commit: ldap/libraries/libldap init.c ldap-int.h
by Hallvard B Furuseth 13 Jan '11

13 Jan '11

hyc(a)OpenLDAP.org writes: > Silence stupid MUTEX_FIRSTCREATE warnings And here I was hoping these warnings would prompt someone to pick up ITS#5421/"librewrite & co vs. logging & ldap-int.h" (-devel nov 2010)... -- Hallvard

1 0

Re: ITS#6607 to be fixed in 2.4.24?
by Quanah Gibson-Mount 10 Jan '11

10 Jan '11

--On Saturday, January 08, 2011 7:32 PM +0100 masarati(a)aero.polimi.it wrote: >> With 2.4.23, i ran into the bug in IDS#6607 "Forwarded bind failure >> messages cause success", but was able to fix it by applying the minor >> diff of back-ldap/chain.c rev 1.77 (as was mentioned in the bug >> follow-up). >> >> I've downloaded RE24 as of today & compiled it up. However, the bug is >> still there. Is this fix going to make it into 2.4.24 by any chance? > > That fix was related to ITS#6475, but apparently is beneficial in other > issues. Right now, ITS#6475 is not going to be released with 2.4.24, > although I do not have any objection. In any case, I believe > back-ldap/chain.c 1.77 could be released as 2.4.24. I've dropped just this part of ITS#6475 into RE24. I will mark 6607 as fixed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Re: RE24 testing call #2 (OL2.4.24)
by Brett ＠Google 10 Jan '11

10 Jan '11

make test stops indefinitely at >>>>> Starting test036-meta-concurrency for bdb... PID=15362 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=14534 - Add/Delete done (0). PID=15384 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=13274 - Read done (0). PID=15420 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=13282 - Read done (0). PID=15422 - Read(1000): entry="cn=Entries,cn=Statistics,cn=Monitor". PID=15384 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. PID=13288 - Read done (0). PID=15424 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=15384: ldap_sasl_bind_s: Invalid credentials (49) slapd-bind PID=15424: ldap_sasl_bind_s: Invalid credentials (49) <then nothing> no error the make test just freezes... (12 minutes without any new log output from when i started noticing) maxfieb@qgdevcore ~> uname -a SunOS qgdevcore 5.10 Generic_141414-07 sun4v sparc SUNW,Sun-Fire-T200 Let me know if you want detailed information & to whom to send it. Using sun compiler, 64 bit build.. Cheers Brett On Fri, Jan 7, 2011 at 8:17 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > There have been substantial updates to RE24. Please test! > > Thanks, > Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Wrapping backend operation calls in macros
by Hallvard B Furuseth 10 Jan '11

10 Jan '11

May I wrap all "foo->backend_op(op, rs)" calls in new macros SLAP_OP()/slap_be_op()/slap_bi_op()? It's for ITS#6758, SlapReply cleanup. The macros expand to the original code, except CPPFLAGS=-D"SOMETHING" uncovers a backend.c function with assertions before and after the backend call. Also code using a backend function array (example 4 below) needs tweaks. Four types of changes. Examples, -old +new: - rc = op->o_bd->be_modrdn( op, rs ); /* Operation *op */ + rc = SLAP_OP( op_modrdn, op, rs ); - rc = be->be_operational( op, rs ); /* BackendDB *be */ + rc = slap_be_op( be, op_aux_operational, op, rs ); - rc = bi.bi_op_search( op, rs ); /* BackendInfo bi */ + rc = slap_bi_op( &bi, op_search, op, rs ); /* &be->be_bind == "array of backend function ptrs" hack */ - func = &be->be_bind; ...; rc = func[ which ]( op, rs ); + bi = be->bd_info; ...; rc = slap_bi_op( bi, which, op, rs ); Quanah, the first three are ~150 changes to 50 files, which I expect can be a bother to merge into RE24. I can instead commit the script which makes the diffs, and let you run it when it suits you. (Generate the diffs for RE24 but apply them to HEAD, ignoring rejects, and you have the conflict-free changes. Leaves ~20 needing more care.) Wrapper function and macros: int (slap_bi_op)(BackendInfo*, slap_operation_t, Operation*, SlapReply*); #if !SOMETHING #define slap_bi_op(bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op,rs)) #endif #define slap_be_op(be,which,op,rs) slap_bi_op((be)->bd_info,which,op,rs) #define SLAP_OP( which,op,rs) slap_be_op((op)->o_bd, which,op,rs) SLAP_OP is uppercase since it evaluates op twice, unlike function calls. My current SOMETHING is (defined(USE_RS_ASSERT) && (USE_RS_ASSERT)), which enables the assert(SlapReply OK) macros from ITS#6758. Maybe in this context it should be a more general SLAPD_DEBUG or (defined(SLAPD_DEBUG) ? (SLAPD_DEBUG) : defined(LDAP_TEST)) ? portable.h #defines LDAP_TEST when LDAP_DEVEL, not in releases. Draft patches: <http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt>. -- Hallvard

1 0

Re: RE24 testing call #1 (OL 2.4.24)
by Howard Chu 10 Jan '11

10 Jan '11

This thread started on -devel, it does not belong on -technical. Brett Maxfield wrote: > There is a discussion of solaris threads socket read/write locking issues and > some workarounds at: http://omniorb.sourceforge.net/omni40/omnithread.html > > See "6 Threaded I/O shutdown for Unix" None of this applies to OpenLDAP's code. > Cheers > Brett > > On 08/01/2011, at 9:55 AM, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> > wrote: > >> Doug Leavitt wrote: >>> >>> On 01/ 7/11 08:01 AM, Rein Tollevik wrote: >>>> On 06.01.11 22.48, Quanah Gibson-Mount wrote: >>>>> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik >>>>> <rein(a)OpenLDAP.org <mailto:rein@OpenLDAP.org>> wrote: >>>>> >>>>>> On 04.01.11 23.34, Quanah Gibson-Mount wrote: >>>>>>> Please test RE24 heavily. >>>>>> >>>>>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It >>>>>> hangs in the monitor, triggered by the new swamp -SS option added to >>>>>> slapd-tester. It works if run with -S or -SSS. It is the third server >>>>>> that hangs, and it does so quite consistently with the same stack trace >>>>>> every time. A gdb trace is at at: >>>>>> >>>>>> ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt >>>>> >>>>> Does this happen on both HEAD and RE24, or RE24 only? >>>> >>>> Both, as well as when running the head tests suite with the 2.4.23 >>>> release. Looks as if the swamp additions have tripped into an >>>> existing problem, not anything new. Leave it out of RE24 until if >>>> have been resolved? >>>> >>>> Btw, any other Solaris test runs out there? I´t like to know if it is >>>> a real Solaris problem or just me.. >> >> I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually >> locks up in test036 for me, I never get as far as test039. The gdb trace >> looks much the same as what you posted. >> >> Looks like for some reason threads that are blocked waiting for their >> sockets to become writable are never getting waken up. A regular SIGINT >> shuts down slapd cleanly so it doesn't appear to be a problem with the >> condvars being used to manage the threads. That kinda points to select() >> simply not returning the writable status. >> >> I haven't used this Solaris machine much, but in fact (looking at the >> remnants of other files in my source tree on this box) this appears to have >> been a problem since at least last August. (I.e., it looks like I was >> investigating this same problem back then but dropped it and never got back >> to it.) >> >>>> Rein >> >>> I'm currently testing Solaris11 (Nevada) and not seeing any issues in >>> either 32 or 64 >>> bit builds using both RE24 and HEAD. I have not had any failures on >>> x86 yet. >>> Testing is still underway for sparc and other internal system testing on >>> both platforms. -- -- 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

RE24 testing call #1 (OL 2.4.24)
by Brett Maxfield 10 Jan '11

10 Jan '11

> There is a discussion of solaris threads socket read/write locking issues and some workarounds at: http://omniorb.sourceforge.net/omni40/omnithread.html > > See "6 Threaded I/O shutdown for Unix" > > Cheers > Brett > > On 08/01/2011, at 9:55 AM, Howard Chu <hyc(a)symas.com> wrote: > >> Doug Leavitt wrote: >>> >>> On 01/ 7/11 08:01 AM, Rein Tollevik wrote: >>>> On 06.01.11 22.48, Quanah Gibson-Mount wrote: >>>>> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik >>>>> <rein(a)OpenLDAP.org> wrote: >>>>> >>>>>> On 04.01.11 23.34, Quanah Gibson-Mount wrote: >>>>>>> Please test RE24 heavily. >>>>>> >>>>>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It >>>>>> hangs in the monitor, triggered by the new swamp -SS option added to >>>>>> slapd-tester. It works if run with -S or -SSS. It is the third server >>>>>> that hangs, and it does so quite consistently with the same stack trace >>>>>> every time. A gdb trace is at at: >>>>>> >>>>>> ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt >>>>> >>>>> Does this happen on both HEAD and RE24, or RE24 only? >>>> >>>> Both, as well as when running the head tests suite with the 2.4.23 >>>> release. Looks as if the swamp additions have tripped into an >>>> existing problem, not anything new. Leave it out of RE24 until if >>>> have been resolved? >>>> >>>> Btw, any other Solaris test runs out there? I´t like to know if it is >>>> a real Solaris problem or just me.. >> >> I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually locks up in test036 for me, I never get as far as test039. The gdb trace looks much the same as what you posted. >> >> Looks like for some reason threads that are blocked waiting for their sockets to become writable are never getting waken up. A regular SIGINT shuts down slapd cleanly so it doesn't appear to be a problem with the condvars being used to manage the threads. That kinda points to select() simply not returning the writable status. >> >> I haven't used this Solaris machine much, but in fact (looking at the remnants of other files in my source tree on this box) this appears to have been a problem since at least last August. (I.e., it looks like I was investigating this same problem back then but dropped it and never got back to it.) >> >>>> Rein >> >>> I'm currently testing Solaris11 (Nevada) and not seeing any issues in >>> either 32 or 64 >>> bit builds using both RE24 and HEAD. I have not had any failures on >>> x86 yet. >>> Testing is still underway for sparc and other internal system testing on >>> both platforms. >> >> -- >> -- 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

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