[Fwd: Re: imporvement to slapo-constraint (ITS#4987)]
by Gavin Henry
It would help if you sent it to openldap-devel! ;-)
---------------------------- Original Message ----------------------------
Subject: Re: imporvement to slapo-constraint (ITS#4987)
From: "Emmanuel Dreyfus" <manu(a)netbsd.org>
Date: Sat, July 7, 2007 8:15 pm
To: "Gavin Henry" <ghenry(a)suretecsystems.com>
Cc: openldap-its(a)openldap.org
--------------------------------------------------------------------------
Gavin Henry <ghenry(a)suretecsystems.com> wrote:
> It would be best to move this dicussion to openldap-devel(a)openldap.org now.
Let's go...
Summarry: I've added a new feature to slapo-constraint for constraining
a value attribute the the existing values of another attribute. The idea
is that you can have a catalog of allowed values (eg: for titles: Mr,
Mrs, Miss) and constraint an attribute to these values
Before working further on this patch (style, dod), I'd like some feeback
on:
1) the way it's implemented: is there rought bugs, or is the logic fine?
2) configuration syntax: do we keep this one or do we swtich to
something else?
Could someone comment on the patch?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
16 years, 2 months
Google Build Farm Proposal news?
by Gavin Henry
Hi,
Did you get anywhere with your plan Howard for the Google proposal?
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
16 years, 2 months
slapd memory alloc/free functions
by Hallvard B Furuseth
#define LDAP_MEMORY_DEBUG and SLAP_NO_SL_MALLOC breaks slapd in a
number of places. Some of the fixes are straightforward, but others
require more sweeping changes - or leaving LDAP_MEMORY_DEBUG useless,
which it has been for some time anyway.
However the LDAP_MEMORY_DEBUG troubles match a Windows bug: According
to ITS#4901, Windows gets heap corruption unless mallocs done in one
DLL are balanced by frees done from the same DLL.
(I'll summarize memory management at the end, so the uninitiated can
have some clue what I'm talking about.)
The main problem is memory allocated with malloc(), either in
slapd or a library - in particular librewrite. proto-slap.h does
#define free ch_free
unless CH_FREE is #defined. ch_free(malloc(x)) ends up calling
ber_memfree, and LDAP_MEMORY_DEBUG breaks ber_memfree(malloc(x)).
With Windows, the freeing DLL will be liblber instead of librewrite
or whatever.
The simplest fix looks like a global search-and-replace with malloc &
co -> ber_memalloc & co except leaving free (-> ch_free) alone in
slapd. (Or use LDAP_MALLOC, LBER_MALLOC and SLAP_MALLOC and friends
instead. They all expand to ber_memalloc & co.) Is there a reason
why we use both malloc() and ber_memalloc()? Functionality aside,
it also makes the code harder to read (and to search for bugs).
I think it should be done in librewrite at least, since it is used
to insert data into ber_memalloced data structures in slapd's.
I suppose such a change could break some Windows module which by
somehow explicitly uses _current_ free vs ber_memfree vs ber_memfree_x
correctly - in particular if it uses librewrite as a library outside
of slapd. Should we worry? Maybe librewrite should have its own
memory handler functions which can be overridden like liblber's.
Regarding the '#define free ch_free' in slapd, I'm not convinced that
is a good idea. I'm sure it has saved some code which wrote free
where it should have written ch_free, but it also makes it even harder
to see what is going on - and apparently it can break slapd modules
that use malloc() - free() on Windows. Maybe we should begin to phase
it out. (First stage: /free/ch_free/ in slapd, #define CH_FREE in all
slapd .c files, and make the #define free ch_free in slap.h cause some
warning. Then wait indefinitely for modules to follow suit.)
Summary of OpenLDAP memory management, as I understand it --
Some memory is allocated with plain malloc, but most via ber_mem*()
functions in liblber. Of those, the ones ending with "_x" take an
extra "context" argument. If you pass a non-NULL context and you
have set malloc handler functions in liblber, ber_*_x() call these
with the context. Otherwise they call plain malloc() co.
slapd also has thread-local malloc heaps, used by slap_sl_malloc() &
co. A thread can have a context, which has a reference to the
thread's heap. Threads must not free/alloc in other threads' heaps.
This avoids locks or mutexes which malloc() needs to ensure that two
concurrent malloc()s do not corrupt malloc()'s heap. Slapd can use
them for memory which gets allocated and freed while handling a
single request (which gets handled by a single thread), I think.
slapd sets slap_sl_free() co or wrappers around them as memory
handlers, and a special ch_free() for the free() handler.
Since it can be a bit hard to keep track of which memory comes from
where, ch_free() fetches the current thread's context if passed a
NULL context. Then it calls slap_sl_free if there is a context,
ber_memfree otherwise. slap_sl_free in turn checks if the memory to
be freed came from the context's heap, otherwise it passes it on to
ber_memfree() without a context. With the '#define free ch_free', a
free/ch_free/slap_sl_free/ber_memfree_x() ends up in the right
place. Except if you try to free another thread's memory, or use
ber_memfree[_x]() without a context to free a thread's memory,
or try to free something from a plain malloc() on Windows.
Oh, and finally there are wrapper functions and macros.
LBER_MALLOC, LDAP_MALLOC, SLAP_MALLOC and friends, which expand to
ber_memalloc & co. ch_malloc() and friends in slapd, which check
that the malloc was successful and exit otherwise. (Naughty, we
really ought to phase out that someday.)
--
Regards,
Hallvard
16 years, 2 months
Alphabetised defines.sh?
by Gavin Henry
Dear all,
I've been trying to follow defines.sh to find a few variables. Is there
any reason the individual sections aren't alphabetised?
Just wondering ;-)
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
16 years, 2 months
loglevel index intention?
by Quanah Gibson-Mount
I noticed that loglevel index is unused by anything currently, and I was
wondering what the intention was initially behind that loglevel. There are
a number of back-bdb/hdb error messages that get generated around indices
that currently come out at the "any" level. I thought perhaps index might
be better for them, but wasn't sure of the intent.
--Quanah
16 years, 2 months
Re: commit: ldap/servers/slapd/back-perl SampleLDAP.pm
by Gavin Henry
<quote who="hallvard(a)OpenLDAP.org">
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-perl
>
> Modified Files:
> SampleLDAP.pm 1.12 -> 1.13
>
I've run Perl::Critic over this and fixed/updated to latest "Perl Best
Practices". We might as well have an up to date sample.
Do you mind if I commit my changes?
cpan Perl::Critic
perlcritic -1 SampleLDAP.pm
Then fixed accordingly.
Thanks,
Gavin.
16 years, 2 months
