(ITS#6951) pcache: valgrind reports some errors when bind-caching is enabled
by ralf＠OpenLDAP.org
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.
11 years, 8 months
Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by fumiyas＠osstech.jp
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
11 years, 8 months
Re: (ITS#6941
by rhafer＠suse.de
> Some how this got duplicated from ITS#6940, please close.
Done.
11 years, 8 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it
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.
11 years, 8 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu
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
11 years, 8 months
(ITS#6949) OpenLDAP Logging
by andrew.stringer＠igt.com
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.
11 years, 8 months
Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it
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.
11 years, 8 months
RE: (ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com
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
11 years, 8 months
