openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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

02 Apr '07

--On Monday, April 02, 2007 7:44 PM +0000 quanah(a)stanford.edu wrote: > > > --On Monday, April 02, 2007 9:42 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> quanah(a)stanford.edu wrote: >> >>> 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 >> >> There it is: "limits" is a database specific directive appearing >> __after__ overlay instantiation. Try moving all database-specific >> directives __before__ any overlay instantiation. > > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. In any case, reordering the slapd.conf files so the overlay stuff all appears last has definitely fixed it. Yeah, and thanks. :) There's a lot I'm looking forward to in 2.4. --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#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 12:42 PM -0700 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. That doesn't seem to be it either. For example, on my master, I have: database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" # Syncrepl Provider overlay syncprov syncprov-checkpoint 1000 60 # Dynamic Group Overlay overlay dyngroup # Uniqueness Overlay overlay unique unique_base cn=people,dc=stanford,dc=edu unique_attributes suunivid suproxycardnumber sucardnumber suuniqueidentifier # Valsort Overlay overlay valsort valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted #valsort-attr ou cn=people,dc=stanford,dc=edu weighted #valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted #valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group="cn=ldapreplica,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Save the time that the entry gets modified lastmod on # Set the location of where the database storage files go. 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 # # Automatically remove log files that are no longer needed. dbconfig set_flags DB_LOG_AUTOREMOVE # # Setting set_tas_spins reduces resource contention from multiple clients on systems with multiple CPU's. dbconfig set_tas_spins 1 # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 1024 5 # Indices to maintain index default eq index cn index dc index entryCSN index entryUUID index objectClass index krb5PrincipalName index suCardNumber index suGeneralID index suProxyCardNumber index suRegID index suUniqueIdentifier index suUnivID index uid ####################################################################### # back-monitor database definitions ####################################################################### database monitor As you can see, *multiple* overlay statements and directives, prior to the "limits" command. It does not exhibit the problems I see on my replica. The issue only arises once dynlist is enabled. --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#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

Quanah Gibson-Mount wrote: > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. Well, the issue is subtle. You risk inconsistency whenever an overlay supports back-config __and__ the out-of-order directive uses some special back-config feature, like the possibility to directly write a value to the database/overlay structure. The way back-config statement/data structure resolution is designed in re23, the out-of-order directive will use the wrong data structure, thus resulting at least in breaking the configuration but, in some cases, in breaking the consistency of the process, by randomly writing, for example, on the stack or on the heap. This should be now fixed in HEAD, but the fix was not so easy to backport because back-config significantly changed in the meanwhile. So, since usually there is no need to write out-of-order statements (back-meta could be an exception, but fortunately enough it doesn't support back-config yet :), there is no pressure for fixing this issue in re23. 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#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 9:42 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: > >> 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 > > There it is: "limits" is a database specific directive appearing > __after__ overlay instantiation. Try moving all database-specific > directives __before__ any overlay instantiation. Ah, I see... So its not just global/db. So all overlay bits should be listed last? And I assume this only happens when you have more than one overlay in use? Because it only happens once both valsort and dynlist are enabled. --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#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: > 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 There it is: "limits" is a database specific directive appearing __after__ overlay instantiation. Try moving all database-specific directives __before__ any overlay instantiation. 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 ando＠sys-net.it 02 Apr '07

02 Apr '07

Please keep replies on the ITS: the "T" stands for "tracking". Wei Weng wrote: > I just installed 2.3.34 version that was found to be the latest > "Release" from openLDAP. Not only there isn't any mention of > LDAP_DEPRECATED, in OpenLDAP 2.3 source tree: bash-3.00$ grep LDAP_DEPRECATED -rI include/ include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED > but there isn't manpage for the new ldap_initialize > function either. You're right, it's only been released starting with 2.4. > I am just very surprised that a quite mature openLDAP open source > projects can be this careless about the documentation. I already explained the reason in my previous posting. It's not lack of care, it's optimization of resources. The code works fine also without documentation, which eventually will converge (and it __is__ converging, in OpenLDAP 2.4). > There is (only > place) mention of ldap_initialize function in ldap.3: "A session handle > is created using ldap_initialize(3)". Naturally you want to do a man > ldap_initialize but there is nothing. ITS#3947 addresses this issue. > I was reporting this bug so that the "newbies" (new to openLDAP APIs) > won't be stuck like I was for a few hours. Then you probably should have entitled your posting "some C API man pages seem to be missing from OpenLDAP 2.3 code", or even better "this is a duplicate of ITS#2240". > Isn't the "Documentation" > supposed to help you to understand the APIs? This is not a bug. This is missing documentation, which is different. It is a known issue (ITS#2240), so your post is only adding noise. A non-noisy posting would have been accompanied by a patch fixing the issue, which is however already fixed in re24 (that's why ITS#2240 is now closed). > By the way, if you guys ask me to supply patch for the ldap_initialize, > sorry, I was just maintaining the old code to try to compile it on a > Fedora 5 box. The details about ldap APIs is above my ability. > > PS: ldap_initialize is just an example, there are also a bunch of other > functions that seemed to have been deprecated. Please check OpenLDAP 2.4. 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 10:59 AM -0700 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > > 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 will also note that ldap_initialize has a man page in the 2.4 release: <http://www.openldap.org/software/man.cgi?query=ldap_initialize&apropos=0&se…> --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#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

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