openldap-bugs May 2011

openldap-bugs@openldap.org

33 participants
70 discussions

(ITS#6951) pcache: valgrind reports some errors when bind-caching is enabled
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf I get this when starting a bind-caching slapo-pcache setup under valgrind: ==18290== Invalid write of size 1 ==18290== at 0x59628F: ftemp_attrs (pcache.c:490) ==18290== by 0x5A29E0: pc_cf_gen (pcache.c:4199) [..] ==18290== Address 0x768dcc6 is 0 bytes after a block of size 6 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x596206: ftemp_attrs (pcache.c:448) [..] ==18290== ==18290== Invalid write of size 1 ==18290== at 0x5A3153: pc_cf_gen (pcache.c:4281) [..] ==18290== Address 0x768e437 is 0 bytes after a block of size 7 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x5A30D5: pc_cf_gen (pcache.c:4270) [..] A fix is on the way to HEAD.

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by fumiyas＠osstech.jp 24 May '11

24 May '11

At Thu, 28 Apr 2011 18:05:43 GMT, mslby(a)deshaw.com wrote: > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. Are you using Solaris nss_ldap and ldap_cachemgr(1M) on your Solaris 10 with OpenLDAP slapd? If so, Solaris libldap.so breaks your slapd process as the following scenario: (1) slapd calls some name service functions, e.g. getpwnam(3C). (2) Solaris nss_ldap (/usr/lib/nss_ldap.so.1) is loaded. (3) Solaris libldap.so (/usr/lib/libldap.so.5) is loaded. (4) Solaris libldap.so overrides ldap_*() and ber_*() functions in slapd (or OpenLDAP libldap_r.so and liblber.so). (5) OpenLDAP calls ldap_*() and ber_*() functions that are belong to Solaris libldap.so, not OpenLDAP's one. See also: http://www.openldap.org/lists/openldap-technical/200902/msg00000.html https://bugzilla.mozilla.org/show_bug.cgi?id=292127 http://bugzilla.padl.com/show_bug.cgi?id=203 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/ > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated

1 0

Re: (ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by Ralf Haferkamp 24 May '11

24 May '11

'1.1' is also causing a crash (on shutdown)

1 0

(ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf The pcache overlay crashes slapd when using * or + in a pcacheAttrset. It seems the problem was introduced with the recent changes to support caching of undefined attributes. Fix is on the way.

1 0

Re: (ITS#6941
by rhafer＠suse.de 24 May '11

24 May '11

> Some how this got duplicated from ITS#6940, please close. Done.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 24 May '11

24 May '11

On 05/23/2011 10:15 PM, Tim.Mooney(a)ndsu.edu wrote: > Thank you Pierangelo. We've been running with that patch since last > Friday without problems, so I'm comfortable with the fix. > > If you can do so without having to spend much time on it, could you give > a brief overview of what you believe might be involved in implementing the > longer fix? I won't make any promises, but if you give me a hint at what > would be involved, I might be able to contribute the code to skip mapping > when not needed. That seems like it would be very beneficial. I don't think it's worth the effort, because mapping and rewriting are somehow tightly joined, so as soon as the overlay is loaded it is nearly always worth to scan all data to check whether intervention is needed. Further optimization would make the code even more hairy without significant improvements. p.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 23 May '11

23 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: >> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, >> masarati(a)aero.po...: >> >>> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >>> checks whether there is anything it can/need to do about special >>> attributes, and it (incorrectly) assumed attributes have an equality rule. >>> It has nothing to do with the fact that you defined no rules for search >>> or so. >>> >>> The quick fix would be to check whether sat_equality is NULL; the >>> (possibly) long fix would be to entirely skip mapping when not needed. >> >> My apologies for the delay in responding. >> >> I've uploaded a patch, >> >> TimMooney-110520.patch >> >> to incoming. It tests that sat_equality is not NULL before dereferencing. >> >> Is this essentially what you had in mind as a fix? > > Yes. Fixed in HEAD. Thanks, p. Thank you Pierangelo. We've been running with that patch since last Friday without problems, so I'm comfortable with the fix. If you can do so without having to spend much time on it, could you give a brief overview of what you believe might be involved in implementing the longer fix? I won't make any promises, but if you give me a hint at what would be involved, I might be able to contribute the code to skip mapping when not needed. That seems like it would be very beneficial. Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

1 0

(ITS#6949) OpenLDAP Logging
by andrew.stringer＠igt.com 23 May '11

23 May '11

Full_Name: Andrew Stringer Version: @(#) $OpenLDAP: slapd 2.3.43 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.205.160.142) Software Enhancement Requests Hi, we are currently rebuilding our LDAP tree using vendor current version of software, including openLDAP. I don't have much LDAP experience, so may be there is already a way to do this, but I have not found it despite several trips to Google. etc.. Logging in openldap seems to be all via syslog and controlled by a value made up by adding the code for a particular log entry of interest, all of which are sent to syslog under one facility number. I feel that logging could be improved by allowing logging similar to how BIND's named does it, namely having different log files for queries, normal operational logs and zone transfers (or in LDAP's case, replications). This would make it much easier to monitor the activity of the server without having to grep out unwanted information to see the required detail. Regards, Andrew.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 23 May '11

23 May '11

On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: > In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > >> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >> checks whether there is anything it can/need to do about special >> attributes, and it (incorrectly) assumed attributes have an equality rule. >> It has nothing to do with the fact that you defined no rules for search >> or so. >> >> The quick fix would be to check whether sat_equality is NULL; the >> (possibly) long fix would be to entirely skip mapping when not needed. > > My apologies for the delay in responding. > > I've uploaded a patch, > > TimMooney-110520.patch > > to incoming. It tests that sat_equality is not NULL before dereferencing. > > Is this essentially what you had in mind as a fix? Yes. Fixed in HEAD. Thanks, p.

1 0

RE: (ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 22 May '11

22 May '11

Hello Quanah, Our slapd uses back-meta to communicate to other slapds. We have to fulfill some requirements related with bandwith with network latencies and packet loss between slapds, to fulfill such requirements we need to increase these threads. Best Regards -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: viernes, 20 de mayo de 2011 19:01 To: Jorge Perez Burgos; openldap-its(a)openldap.org Subject: Re: (ITS#6944) Add option to limit or remove operation list cache --On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2011