openldap-bugs

openldap-bugs@openldap.org

1 participants
20958 discussions

Re: (ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 9:09 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: >> 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). I've looked at the ITS, and I don't think it is related. As far as I know, everything in it is specifically located where it should be (global bits in the global area, database specific bits in the database areas): My slapd.conf is: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/krb5-kdc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/eduperson.schema include /usr/local/etc/openldap/schema/stanford-oids.schema include /usr/local/etc/openldap/schema/suacct.schema include /usr/local/etc/openldap/schema/superson.schema include /usr/local/etc/openldap/schema/suapplication.schema include /usr/local/etc/openldap/schema/suorg.schema include /usr/local/etc/openldap/schema/eduorg.schema include /usr/local/etc/openldap/schema/suworkgroup.schema allow bind_v2 TLSCertificateFile /usr/local/etc/openldap/stardomain.crt TLSCertificateKeyFile /usr/local/etc/openldap/stardomain.key TLSCACertificateFile /usr/local/etc/openldap/comodo.pem include /usr/local/etc/openldap/slapd.acl pidfile /var/run/slapd.pid argsfile /var/run/slapd.args defaultsearchbase "dc=stanford,dc=edu" gentlehup off loglevel 256 threads 8 tool-threads 2 sasl-realm stanford.edu sasl-authz-policy both sasl-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanford.edu sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active reverse-lookup on modulepath /usr/local/lib/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload valsort.la moduleload dynlist.la database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" overlay valsort valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted overlay dynlist dynlist-attrset groupOfURLS memberURL member limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=athletics,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=workgroup-audit,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=RegistryDataAuditor,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=ispace,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=5000 size.hard=5000 limits dn.exact="cn=gsb-person,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited lastmod on syncrepl rid=0 provider=ldap://ldap-devmaster.stanford.edu:389 bindmethod=sasl saslmech=gssapi realm=stanford.edu searchbase="dc=stanford,dc=edu" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog # Replica Directives updateref ldap://ldap-devmaster.stanford.edu directory /var/lib/ldap dbconfig set_cachesize 3 536870912 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/bdb dbconfig set_lk_max_locks 3000 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_lockers 1500 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_tas_spins 1 checkpoint 1024 5 cachesize 50000 idlcachesize 50000 cachefree 1000 index_substr_any_len 3 index default eq (Long list of indices) database monitor -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4904) delta-sync can free modlist redundantly
by hyc＠OpenLDAP.org 02 Apr '07

02 Apr '07

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.

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

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 ------------------------------------------

1 0

(ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

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

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by ando＠sys-net.it 02 Apr '07

02 Apr '07

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 ------------------------------------------

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--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

1 0

(ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by wweng＠kencast.com 02 Apr '07

02 Apr '07

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.

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Saturday, March 31, 2007 12:54 AM +0000 quanah(a)stanford.edu wrote: > --On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > >> Full_Name: Chris Ridd >> Version: 2.3.34 >> OS: Windows >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (62.3.217.250) >> >> >> On Windows, it is important that mallocs done in one DLL are balanced by >> frees done from the same DLL. Failure to do this consistently leads to >> heap corruption. >> >> This was observed to occur in several places in ldapadd - several buffers >> allocated by ber_memfree() were freed using free(). >> >> Our customer has successfully used a version of ldapadd on Windows >> containing this patch (and the one in ITS 4900.) > > Thanks, testing. --- openldap-2.3.34/clients/tools/common.c.orig Fri Mar 30 15:17:32 2007 +++ openldap-2.3.34/clients/tools/common.c Fri Mar 30 15:21:42 2007 @@ -1244,7 +1244,7 @@ crit ? "critical " : "" ); } - free( ctrls ); + ldap_controls_free( ctrls ); if ( crit ) { exit( EXIT_FAILURE ); } Just to note, this part of the patch is bad. ctrls is a pointer to an array of controls, not an array of controls itself. Therefore, the use of "free" here is appropriate. Using ldap_controls_free results in segfaults. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, it is important that mallocs done in one DLL are balanced by > frees done from the same DLL. Failure to do this consistently leads to > heap corruption. > > This was observed to occur in several places in ldapadd - several buffers > allocated by ber_memfree() were freed using free(). > > Our customer has successfully used a version of ldapadd on Windows > containing this patch (and the one in ITS 4900.) Thanks, testing. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4900) command-line utils crash
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Friday, March 30, 2007 2:09 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, the ldapadd tool often crashes while parsing the command-line > arguments. Hi Chris, We formally dropped support for MSVC a long time ago. That being said, working build of OpenLDAP was accomplished with MSVCC a few months ago without hitting this issue. Which version of MSVC is being used, and please doublecheck the conditions spelled out in the comments in <ldap_cdefs.h>, where it starts with "Support for Windows DLLs". Also, instead of declaring things as extern, does changing LDAP_LIBC_V to LDAP_LUTIL_V resolve your issue? --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

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