openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by hyc＠symas.com 07 Jul '09

07 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: CVS HEAD (2.4.16+) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch > Submission from: (NULL) (76.113.59.19) > > > This patch allows liblutil to provide the LDIF reading and writing functions as > public APIs in a libldif, and exposes ldif.h to the public API. See also ITS#4033; ldif.h only parses LDIF into chunks/records, it's still up to the caller to turn these records into something meaningful. In fact libldif used to be a library of its own, but in RE22 we made the decision to merge it into liblutil because its functionality is so limited. I don't expect we'll reverse this decision unless/until it gets enough parsing added to it to make it more generally useful. > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not > assigned rights and/or interest in this work to any party. I, Richard > Megginson am authorized by Red Hat, Inc., my employer, to release this > work under the following terms. > > Red Hat, Inc. hereby place the following 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. -- -- 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#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

I've been trying to factor this MUSTRELEASE/MUSTBEFREED stuff out to some macros. Easier said than done, I ended up with the macro monstrosity below. Do I put that in slap.h? Or a separate slap-response.h file? Generally the idea is that most code which modifies rs->sr_<entry/matched/ref/ctrls> (as opposed to initializing) should use these macros, which obey sr_flag and dispose of the old value if needed. There won't be that many callers actually, mostly overlays. There is overlay code which need to be rearranged a bit or which can't use this, and there is overlay code I don't understand at all and don't dare touch. Oh, and this seems to be wrong for how sr_ctrls are set up, which seems to be allocated differently some places. I'm just including that for reference for now, won't commit it yet in any case. Finally, code which aborts normal processing of some response and instead send an error often needs to be fixed - it often doesn't flush SlapReply data, and the data to be flushed and maybe freeed can be lost because it's overwritten. Generally I think code which modifies sr_type (or in some cases calls a function which will do so) should be responsible for flushing old SlapReply data first. #define REP_ENTRY_MUSTFLUSH (REP_ENTRY_MUSTBEFREED|REP_ENTRY_MUSTRELEASE) #define REP_ENTRY_MASK (REP_ENTRY_MODIFIABLE |REP_ENTRY_MUSTFLUSH) #define REP_MATCHED_MUSTFLUSH REP_MATCHED_MUSTBEFREED #define REP_REF_MUSTFLUSH REP_REF_MUSTBEFREED #define REP_CTRLS_MUSTFLUSH REP_CTRLS_MUSTBEFREED /* Macros updating freeable members of SlapReply, mostly for overlays. */ /* * Ensure rs->sr_entry is modifiable, by duplicating it if necessary. * Obey sr_flags. Set REP_ENTRY_<MODIFIABLE, and MUSTBEFREED if duplicated>. * Do <postmodActions> if the entry was replaced. */ #define RS_MODIFIABLE_ENTRY(op, rs, on, postmodActions) do { \ SlapReply *const rmeRS = (rs); \ if ( rmeRS->sr_flags & REP_ENTRY_MODIFIABLE ) break; \ RS_REPLACE_ENTRY( op, rmeRS, on, entry_dup( rmeRS->sr_entry ), 0 ); \ rmeRS->sr_flags |= REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED; \ postmodActions; \ } while (0) /* Reset rs->sr_<member> if REP_<member>_MUSTBEFREED/MUSTRELEASE says so. */ #define RS_FLUSH_ENTRY(op, rs, on) RS_FLUSH(ENTRY, op, rs, on, 1, {}, {}) #define RS_FLUSH_CTRLS(op, rs) RS_FLUSH(CTRLS, op, rs, -, 1, {}, {}) #define RS_FLUSH_MATCHED( rs) RS_FLUSH(MATCHED, -, rs, -, 1, {}, {}) #define RS_FLUSH_REF( rs) RS_FLUSH(REF, -, rs, -, 1, {}, {}) /* Flush and set rs->sr_<member>. Set REP_<member>_MUSTBEFREED if <isDup>. */ #define RS_REPLACE_ENTRY(op,rs,on,v,isDup) RS_REPLACE(ENTRY,op,rs,on, v,isDup) #define RS_REPLACE_CTRLS(op,rs,v,isDup) RS_REPLACE(CTRLS, op,rs,-, v,isDup) #define RS_REPLACE_MATCHED( rs,v,isDup) RS_REPLACE(MATCHED, -,rs,-, v,isDup) #define RS_REPLACE_REF( rs,v,isDup) RS_REPLACE(REF, -,rs,-, v,isDup) /* Helpers for the above */ #define SR_ENTRY sr_entry #define SR_CTRLS sr_ctrls #define SR_MATCHED sr_matched #define SR_REF sr_ref typedef Entry *SR_ENTRY_t; typedef LDAPControl **SR_CTRLS_t; typedef const char *SR_MATCHED_t; typedef BerVarray SR_REF_t; #define RS_FREE_ENTRY(op, rs, on)\ if ((rs)->sr_flags & REP_ENTRY_MUSTBEFREED) { \ assert (!(rs)->sr_flags & REP_ENTRY_MUSTRELEASE); \ entry_free((rs)->sr_entry); \ } \ else if (on == NULL) be_entry_release_rw(op, (rs)->sr_entry, 0);\ else overlay_entry_release_ov(op, (rs)->sr_entry, 0, on) #define RS_FREE_CTRLS(op, rs, on) slap_free_ctrls( op, (rs)->sr_ctrls ) #define RS_FREE_MATCHED(op, rs, on) ch_free( (char *) (rs)->sr_matched ) #define RS_FREE_REF(op, rs, on) ber_bvarray_free( (rs)->sr_ref ) #define RS_FLUSH(MEMBER, op, rs, on, reset, preActions, postActions) do { \ SlapReply *const rfRS = (rs); \ preActions; \ if ( rfRS->sr_flags & REP_##MEMBER##_MUSTFLUSH ) { \ if ( rfRS->SR_##MEMBER ) { \ RS_FREE_##MEMBER( op, rfRS, on ); \ if ( reset ) rfRS->SR_##MEMBER = NULL; \ } \ } \ rfRS->sr_flags &= ~REP_##MEMBER##_MASK; \ postActions; \ } while (0) #define RS_REPLACE(MEMBER, op, rs, on, val, isDup) \ RS_FLUSH( MEMBER, op, rs, on, 0, \ SR_##MEMBER##_t const rfNewval = (val), \ if ( isDup ) rfRS->sr_flags |= REP_##MEMBER##_MUSTBEFREED; \ rfRS->SR_##MEMBER = rfNewval ) /* Warn if something re#defines the following, which would break RS_REPLACE */ #define ENTRY ENTRY #define CTRLS CTRLS #define MATCHED MATCHED #define REF REF

1 0

Re: (ITS#5892) slapadd doesn't fail on invalid include statements
by hyc＠symas.com 07 Jul '09

07 Jul '09

aredridel(a)nbtsc.org wrote: > Full_Name: Aria Stewart > Version: 2.4.13 > OS: PLD Linux (Th) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:8935:7:21b:fcff:fe77:1757) > > > An ldif file with include statements in the form of: > > include: /filename > > rather than > > include: file:///filename > > silently fail. Slapadd stops at that point, but does not print an error message. Oops, the library has provided an error message for this instance since 2.4.5beta (September 2007) but slapadd wasn't enabling the display of that message by default. This is now fixed in HEAD. -- -- 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#6101) Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

I wrote: > We need to check > grep -nH -e 'SlapReply[<tab> ]*[a-zA-Z]' *.c */*.c > for other cases. Not for this ITS. Just moved sru_search first in the union. It's not always clear to me which code is responsible for initializing SlapReply anyway. Fixed two other simple cases: - result.c:send_ldap_disconnect() should reset rs->sr_rspdata. - sasl.c: should (re)set rs->sr_sasldata before doing send_ldap_sasl(). -- Hallvard

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 07 Jul '09

07 Jul '09

--On Tuesday, July 07, 2009 4:41 PM +0000 quanah(a)zimbra.com wrote: > Also, please confirm what BDB version you are using, including if it has > all patches applied and compile options for BDB, and which backend you > are using. Hi Jorge, Please also confirm that you have writetimeout configured in your slapd configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 07 Jul '09

07 Jul '09

--On Tuesday, July 07, 2009 12:51 PM +0000 jorge.perez(a)adaptia.net wrote: Hello, > > The problem still reproduces. Threads hung on the same > ptread_cond_wait.call. This time the assert has not failed. > > Thread 18 (Thread 1390426432 (LWP 17780)): > ---Type <return> to continue, or q <return> to quit--- ># 0=C2=A0 0x00002b5a8515b1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 ># 1=C2=A0 0x00000000004525a4 in send_ldap_ber (op=3D<value optimized out>, > ber=3D0x52e01150) at result.c:156 ># 2=C2=A0 0x000000000045449e in slap_send_search_entry ># (op=3D0x2b5a849138f4, > rs=3D0x52e02da0) at result.c:1259 > Hi Jorge, We're going to need more information from you than you are providing. Please make sure you: (a) build openldap without optimization (-O0) (b) are gdbing the process, not a core file (c) Send a full backtrace of everything: thr apply all bt full Also, please confirm what BDB version you are using, including if it has all patches applied and compile options for BDB, and which backend you are using. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

Also ldap_err2string(), unlike ldap_perror(), does not pass messages from recognized result codes through _() - i.e. the optional gettext(). I'll fix that too. -- Hallvard

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 07 Jul '09

07 Jul '09

hyc(a)symas.com writes: > This code has changed in HEAD. Closing this ITS. Hm? The unlock-lock is still there. If it still needs to let through another thread to c_write1_mutex I don't see how the connection_valid() test in front of it helps. -- Hallvard

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 07 Jul '09

07 Jul '09

On Mon, Jul 6, 2009 at 9:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > >> >> With the debug symbols there's an assert that fails in slapd_clr_write >> method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): > > Thanks. =C2=A0The hang should really be fixed now. :P =C2=A0Please re-syn= c RE24 and test again. =C2=A0Thank you! Hello, The problem still reproduces. Threads hung on the same ptread_cond_wait.call. This time the assert has not failed. Thread 18 (Thread 1390426432 (LWP 17780)): ---Type <return> to continue, or q <return> to quit--- #0=C2=A0 0x00002b5a8515b1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1=C2=A0 0x00000000004525a4 in send_ldap_ber (op=3D<value optimized out>, ber=3D0x52e01150) at result.c:156 #2=C2=A0 0x000000000045449e in slap_send_search_entry (op=3D0x2b5a849138f4, rs=3D0x52e02da0) at result.c:1259 Regards

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 07 Jul '09

07 Jul '09

On 02/10/2009 09:53 AM, hyc(a)symas.com wrote: > I opted for this approach, now checked into HEAD. Please test. After few months in production it seems the bug is gone. Thanks a lot for the fix! Jan

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