(ITS#4904) delta-sync can free modlist redundantly
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.3/HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
In syncrepl_message_to_op the modlist is copied to op->orm_modlist and then
freed after op->o_bd->be_modify. But the modify can alter the modlist (e.g.,
ppolicy overlay) causing a redundant free later on.
16 years, 6 months
Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it
quanah(a)stanford.edu wrote:
> Full_Name: Quanah Gibson-Mount
> Version: RE_23
> OS: Linux 2.6 (64-bit)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (171.64.19.81)
>
>
> In testing the RE_23 tree, I put it under hoard after everything passed using
> glibc as the memory allocator. I found that if I enable dynlist:
>
> moduleload dynlist.la
>
> then in my database section add:
>
> # Dynlist Overlay
> overlay dynlist
> dynlist-attrset groupOfURLS memberURL member
>
>
> slapd will core dump on startup with:
>
> Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0
> #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so
> (gdb) bt
> #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so
> #1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so
> #2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available.
> ) at memory.c:354
> #3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518
> "olcConnMaxPending") at charray.c:49
> #4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364
> #5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368
> #6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711
>
>
> It looks like there's soemthing incorrect in the way it is allocating memory on
> startup.
Apparently, there's nothing directly related to dynlist; can you post
the entire slapd.conf? I suspect something like ITS#4848, which is NOT
fixed in re23 (and likely won't).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
(ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: RE_23
OS: Linux 2.6 (64-bit)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.81)
In testing the RE_23 tree, I put it under hoard after everything passed using
glibc as the memory allocator. I found that if I enable dynlist:
moduleload dynlist.la
then in my database section add:
# Dynlist Overlay
overlay dynlist
dynlist-attrset groupOfURLS memberURL member
slapd will core dump on startup with:
Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0
#0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so
(gdb) bt
#0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so
#1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so
#2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available.
) at memory.c:354
#3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518
"olcConnMaxPending") at charray.c:49
#4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364
#5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368
#6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711
It looks like there's soemthing incorrect in the way it is allocating memory on
startup.
--Quanah
16 years, 6 months
Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by ando＠sys-net.it
quanah(a)stanford.edu wrote:
>> I don't know if the people who are in charge to build a RPM are paying
>> attention to what they are doing or not.
>>
>> You can do a man ldap_init, and then look at /usr/include/ldap.h for the
>> function definition.
>>
>> I am not a LDAP expert or anything close to that. But it seems to me that
>> function called ldap_init has already been replaced by the function called
>> ldap_initialize, and they take even different set of parameters.
>>
>> And yet the manpage not only didn't reflect that change, but enforce the
>> wrong idea of using ldap_init function by having ldap_init in manpages.
>>
>> An extremely poor job done by the package maintainer.
>
> Hi,
>
> I suggest you complain to RedHat if you don't like the way they've packaged
> something. The OpenLDAP foundation is not responsible for the way in which
> RedHat packages its releases. In any case, if you are taking the time to
> read the header file, then pay close attention to the following:
>
> #if LDAP_DEPRECATED
> LDAP_F( LDAP * )
> ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */
> LDAP_CONST char *host,
> int port ));
>
>
> I.e., ldap_init is a deprecated function, and ldap_initialize should be
> used instead. However, there are many programs out there that still use
> the old API, so the old functions are maintained for backwards
> compatibility purposes. Hence the man page.
I'd add that OpenLDAP is a voluntary based project, and volunteers
devote their efforts to what they consider mostly important - typically
writing good useful code that runs (fast). Man pages typically lag
behind, but eventually they get updated/fixed (as they are in currently
released code). If you cared so much about up-to-date code and man
pages, you would be using the latest release, not a 15 months old one.
And if you were able to infer the really useful API from ldap.h, you
could have more proficiently spent your time by writing and submitting a
useful man page, instead of just complaining quite unpolitely.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by quanah＠stanford.edu
--On Monday, April 02, 2007 5:23 PM +0000 wweng(a)kencast.com wrote:
> Full_Name: Wei Weng
> Version: 2.3.19
> OS: Linux(Fedora 5)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (69.120.101.108)
>
>
> I don't know if the people who are in charge to build a RPM are paying
> attention to what they are doing or not.
>
> You can do a man ldap_init, and then look at /usr/include/ldap.h for the
> function definition.
>
> I am not a LDAP expert or anything close to that. But it seems to me that
> function called ldap_init has already been replaced by the function called
> ldap_initialize, and they take even different set of parameters.
>
> And yet the manpage not only didn't reflect that change, but enforce the
> wrong idea of using ldap_init function by having ldap_init in manpages.
>
> An extremely poor job done by the package maintainer.
Hi,
I suggest you complain to RedHat if you don't like the way they've packaged
something. The OpenLDAP foundation is not responsible for the way in which
RedHat packages its releases. In any case, if you are taking the time to
read the header file, then pay close attention to the following:
#if LDAP_DEPRECATED
LDAP_F( LDAP * )
ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */
LDAP_CONST char *host,
int port ));
I.e., ldap_init is a deprecated function, and ldap_initialize should be
used instead. However, there are many programs out there that still use
the old API, so the old functions are maintained for backwards
compatibility purposes. Hence the man page.
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Senior Systems Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 6 months
(ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by wweng＠kencast.com
Full_Name: Wei Weng
Version: 2.3.19
OS: Linux(Fedora 5)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (69.120.101.108)
I don't know if the people who are in charge to build a RPM are paying attention
to what they are doing or not.
You can do a man ldap_init, and then look at /usr/include/ldap.h for the
function definition.
I am not a LDAP expert or anything close to that. But it seems to me that
function called ldap_init has already been replaced by the function called
ldap_initialize, and they take even different set of parameters.
And yet the manpage not only didn't reflect that change, but enforce the wrong
idea of using ldap_init function by having ldap_init in manpages.
An extremely poor job done by the package maintainer.
16 years, 6 months
