openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 21 Oct '09

21 Oct '09

Quanah, > So Stanford also uses SASL/GSSAPI, and is hitting a similar issue, > except on read instead of modify. When I take SASL/GSSAPI out of the > picture, the search works fine. Are you able to test doing a simple > bind with the modify to the server and seeing if that works? I can confirm the operation works just fine with simple bind. With all the testing you've done, it doesn't give me a warm fuzzy feeling that this was some simple bug introduced anytime recently. Mark

1 0

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

21 Oct '09

--On Wednesday, October 21, 2009 11:51 AM -0400 Mark Dieterich <mkd(a)cs.brown.edu> wrote: > Quanah, > >> What was the last OpenLDAP version this worked on, server side? > > After you sent me the pointer to the other ITS, I started trying various > combinations of ldapmodify and openldap backends to see if I could > successfully perform this update. Unfortunately, I have yet to make it > work. We first noticed this problem about a five weeks ago. At the > time, we were running openldap on a debian etch server (openldap > 2.3.30). It looks like the package we were running was from late Oct. > 2008, so I suspect this operation never would have worked in our > environment and we just finally hit some threshold. Ok, thanks. So Stanford also uses SASL/GSSAPI, and is hitting a similar issue, except on read instead of modify. When I take SASL/GSSAPI out of the picture, the search works fine. Are you able to test doing a simple bind with the modify to the server and seeing if that works? I was hoping it was some change on the 2.4 server side that caused the issue. I'm able to reproduce Stanford's issue 100% on Linux systems as clients, going back to Heimdal 0.7.2 or MIT krb5 1.5.something, cyrus-sasl 2.1.18->2.1.23, OpenLDAP 2.2.13->2.4.19, openssl 0.9.8a->0.9.8k, and gcc 3.3.5->gcc 4.1.2. However, if I use a Solaris Sparc system with SASL/GSSAPI, I never see the problem, regardless of Kerberos, cyrus-sasl, openssl, gcc, or openldap versions. --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 mkd＠cs.brown.edu 21 Oct '09

21 Oct '09

Quanah, > What was the last OpenLDAP version this worked on, server side? After you sent me the pointer to the other ITS, I started trying various combinations of ldapmodify and openldap backends to see if I could successfully perform this update. Unfortunately, I have yet to make it work. We first noticed this problem about a five weeks ago. At the time, we were running openldap on a debian etch server (openldap 2.3.30). It looks like the package we were running was from late Oct. 2008, so I suspect this operation never would have worked in our environment and we just finally hit some threshold. Sorry I can't be of more help. Mark

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by karavelov＠spnet.net 21 Oct '09

21 Oct '09

masarati(a)aero.polimi.it wrote: >> >> Yes, I have set up rootdn because pcache overlay wanted it. I will set >> also some rootpw to see if this makes difference. >> > > mmmh, sounds like a red herring, sorry for the noise. > > p. > > Hello, The bug seems to be in the new code in pcache overlay handling cache refreshes. When I switched configuration with only TTL/negTTL (without TTR) the crashes have disappeared from both scenarios I have used: 1. One process with back-sql + pcache (crashed with segmentation failt when using TTR) 2. Two processes, first with back-sql, second with back-ldap + pcache, that communicate over unix domain socket (crashed on assertion in entry_clean when using TTR) So the bug is not fixed but is located in pcache > consistency_check > refresh_query Luben

1 0

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

21 Oct '09

--On Tuesday, October 20, 2009 8:19 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, October 20, 2009 6:31 PM +0000 mkd(a)cs.brown.edu wrote: > >> This is a multi-part message in MIME format. >> --------------040906020706060003090803 >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: 7bit >> >> Rein, >> >> Attached is a copy of the failure log running with "-d 271". I cleaned >> up obvious information we don't want out, but don't think I changed the >> underlying data in any meaningful way. Hopefully, I pulled everything I >> needed to ;) > > > I think this is related to ITS#6327. It appears to be a bug specifically > with Linux & SASL, as best I can tell. So far, I've eliminated OpenLDAP, > Cyrus-SASL, and Heimdal vs MIT as the culprit. The only OS I've been > able to run on where this failure does not occur is Solaris. I'm > working on building a 2.4.19 set of libraries on Solaris to confirm that. Hi Mark, What was the last OpenLDAP version this worked on, server side? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6345) tests/progs/slapd-common.c negative array index
by h.b.furuseth＠usit.uio.no 21 Oct '09

21 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard tester_ignore_err(negative error code) does ignore_server[ err ]--; when it should do ignore_client[ -err ]--; Looks like a cut&paste error. Fixing. That piece of code is needlessly complex anyway. Simplifying: Instead of treating positive and negative error codes separately (server-side and client-side codes), all that is needed is a single array for both, offset by (-minimum result code).

1 0

(ITS#6344) ber_put_ostring/ber_put_bitstring ignore error
by h.b.furuseth＠usit.uio.no 21 Oct '09

21 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ber_put_ostring()/ber_put_bitstring() return success if 1st ber_write() succeeds and the 2nd fails. Introduced in OpenLDAP 2.4.18, ITS#6215. Fixing.

1 0

(ITS#6343) test057 broken for --enable-memberof --disable-refint
by h.b.furuseth＠usit.uio.no 21 Oct '09

21 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test057-memberof-refint flunks --enable-memberof --disable-refint. It forgets to check if refint is present. Fixing.

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by h.b.furuseth＠usit.uio.no 21 Oct '09

21 Oct '09

On 29 Jan 2009, I wrote: >ulrich.windl(a)rz.uni-regensburg.de writes: >> To make a long discussion short, you cold add a comment regarding the >> use of "8". > > The 8 should be CHAR_BIT. > > /* Maximum tree depth this host's address space could support */ > #define MAX_TREE_DEPTH (sizeof(void *) * CHAR_BIT) Hm, you reported this against tavl.c and I updated avl.c. Now tavl.c is also updated :-) -- Hallvard

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 21 Oct '09

21 Oct '09

--On Tuesday, October 20, 2009 10:45 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, October 20, 2009 3:34 PM -0700 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> OpenLDAP 2.4.19 + cyrus-sasl 2.1.23 + Heimdal 1.2.1 + OpenSSL 0.9.8k >> works perfectly under solaris for me. > > Also worth nothing the freeze only happens against a 2.4.19 server. > Querying a 2.3.35 server with the same database does not freeze > ldapsearch. Debian sarge, with libc 2.3.2, OpenLDAP 2.2.23, built with gcc 3.3 works. Debian sarge, with libc 2.3.2, OpenLDAP 2.3.13, built with gcc 4.0.3, does *not* work. GCC specific issue? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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