openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6349) Compilation of /libraries/liblutil/getpeerid.c
by hyc＠symas.com 26 Oct '09

26 Oct '09

P.Haering(a)gmx.net wrote: > Full_Name: Peter Häring > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.208.246.19) > > > System: Linux 2.6.31.3 (headers for glibc) > glibc 2.10.1 > gcc 4.4.1 > > Compilation of /libraries/liblutil/getpeerid.c says in Line 65: size of peercred > unknown. Indeed, the struct ucred is never defined. This was already fixed in 2.4.17. The current release is 2.4.19. You should not be building such an old release by this point in time. -- -- 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#6334) hang during ldapmodify
by mkd＠cs.brown.edu 26 Oct '09

26 Oct '09

Quanah, I spent a while playing around this morning. Your request to not use TLS made me realize I never tried the operation without TLS, as we really do want it enabled. It turns out, I can't make my test operation hang without TLS, clearly having TLS enabled is the source of my issues. I'm not sure where this leaves us, but at least it narrows down the search. I still plan to go through the motions with the encode.c, but I'm guessing it won't make any difference once I re-enable TLS. Mark Quanah Gibson-Mount wrote: > --On Friday, October 23, 2009 4:34 PM +0000 mkd(a)cs.brown.edu wrote: > >> I sure hope these make more sense to you than they do to me! Let me >> know if you need anything else. > > If you can rebuild 2.4.19 with the libraries/liblber/encode.c from HEAD > in place, and then generate the same logs for me (using -d 2 for both > ldapmodify and slapd), but please only use SASL/GSSAPI, not > TLS+SASL/GSSAPI, that would be great. > > Thanks, > Quanah

1 0

(ITS#6351) memrchr
by P.Haering＠gmx.net 26 Oct '09

26 Oct '09

Full_Name: Peter Häring Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.208.246.19) In file include/ac/string.h: /* GNU extension (glibc >= 2.1.91), only declared when defined(_GNU_SOURCE) */ #ifndef HAVE_MEMRCHR #undef memrchr #define memrchr lutil_memrchr #endif /* ! HAVE_MEMRCHR */ void * memrchr(const void *b, int c, size_t len); the last two lines must be switched, so that memrchr() is only declared, when HAVE_MEMRCHR is undefined. /* GNU extension (glibc >= 2.1.91), only declared when defined(_GNU_SOURCE) */ #ifndef HAVE_MEMRCHR #undef memrchr #define memrchr lutil_memrchr void * memrchr(const void *b, int c, size_t len); #endif /* ! HAVE_MEMRCHR */

1 0

(ITS#6350) Compilation of /libraries/liblutil/getpeerid.c
by P.Haering＠gmx.net 26 Oct '09

26 Oct '09

Full_Name: Peter Häring Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.208.246.19) System: Linux 2.6.31.3 (headers for glibc) glibc 2.10.1 gcc 4.4.1 Compilation of /libraries/liblutil/getpeerid.c says in Line 65: size of peercred unknown. Indeed, the struct ucred is never defined. There is a definition in /usr/include/bits/socket.h, but this needs that __USE_GNU is defined. My workaround: #define __USE_GNU at the top of the file. This doesn't work, because the definition of fopencookie() in /usr/include/stdio.h then goes wrong (Bug in glibc?) The man page of fopencookie() say to define _GNU_SOURCE, so I defined that additionally. With both defines, compilation works and all tests succeed.

1 0

(ITS#6349) Compilation of /libraries/liblutil/getpeerid.c
by P.Haering＠gmx.net 26 Oct '09

26 Oct '09

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by hyc＠symas.com 24 Oct '09

24 Oct '09

masarati(a)aero.polimi.it wrote: > No. Some overlay along the lines apparently mucks with e_private in the > entry that back-ldap is sending. It's probably slapo-pcache. You're right. Following the debug traces, it's merge_entry which is passing the entry it got from the proxy directly to be_add(). But bdb_add() takes the given entry and inserts it directly into its entry cache, instead of calling entry_dup(). Since this particular entry came from back-ldap's stack, this whole chain of events is doomed to fail. I'll fix this by calling entry_dup() in pcache merge_entry(). -- -- 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#6327) ldapsearch hangs
by quanah＠zimbra.com 24 Oct '09

24 Oct '09

--On Thursday, October 22, 2009 11:31 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, October 22, 2009 6:16 PM +0000 quanah(a)zimbra.com wrote: > >> There's obviously some flaw in length generation somewhere. With changes in HEAD, 3 attr query works, 2 attr query fails. SASL/DIGEST-MD5 works regardless. SASL/GSSAPI seems to be the problem mechanism. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6334) hang during ldapmodify
by quanah＠zimbra.com 23 Oct '09

23 Oct '09

--On Friday, October 23, 2009 4:34 PM +0000 mkd(a)cs.brown.edu wrote: > I sure hope these make more sense to you than they do to me! Let me > know if you need anything else. If you can rebuild 2.4.19 with the libraries/liblber/encode.c from HEAD in place, and then generate the same logs for me (using -d 2 for both ldapmodify and slapd), but please only use SASL/GSSAPI, not TLS+SASL/GSSAPI, that would be great. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6334) hang during ldapmodify
by h.b.furuseth＠usit.uio.no 23 Oct '09

23 Oct '09

libraries/liblber/encode.c in cvs HEAD now fixes two bugs introduced in OpenLDAP 2.4.18: ITS#6344, ITS#6348. Don't know yet if it elimiates or just reduces this bug. If the latter, you may now need to to send even larger modifications to reproduce this bug. -- Hallvard

1 0

(ITS#6348) liblber inverts LBER_USE_DER
by h.b.furuseth＠usit.uio.no 23 Oct '09

23 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard liblber sends sets/sequences with 5-octet length if LBER_USE_DER is set, instead of if it is clear. Introduced in OpenLDAP 2.4.18, ITS#6215. Not a protocol bug, but LDAPMessages can grow quite bigger than needed. Fixing.

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