- openldap-bugs - openldap.org

Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by quanah＠zimbra.com 07 Sep '07

07 Sep '07

--On Friday, September 07, 2007 12:54 PM +0000 ando(a)sys-net.it wrote: > diabeticithink(a)yahoo.com wrote: >> Thank you for the help. I cannot upgrade to a later version of OpenLdap >> because RHEL 4.0 doesn't support it. Bummer, eh? > > Well, there is nothing the OpenLDAP project can do for you, then, other > than providing more than 3 years of development since 2.2.13 (it was > released June 2004), that RedHat in the first place, but basically you > seem to be willing to ignore (it's just one click away: untar, > configure, make, make install). > > Or, you should ask RedHat to either upgrade OpenLDAP in RHEL 4.0, or fix > your specific bug, if any (I still suspect a misconfiguration, possibly > unrelated to OpenLDAP software itself, given that OpenLDAP software does > not generate that specific message). As distributors, they are > responsible for providing you up-to-date software when available (how > responsive they are might depend on the type of maintenance contract you > have with them). Just to note, this has been discussed many times on the software list. RedHat's packages should only be viewed as providing access to the LDAP client API, and *not* as packages to be used for running a production LDAP service. They are not maintained to the level necessary for production usage. I'd strongly advise using the resources already made available elsewhere for running OpenLDAP as a production service. For example, Symas Corp. (employer of Howard Chu, OpenLDAP's Chief Architect) provides free pre-compiled and tested packages of OpenLDAP at <http://www.symas.com>, and Buchan Milne, who is heavily involved with the OpenLDAP project also provides pre-compiled packages of OpenLDAP at <http://staff.telkomsa.net/packages/>. You are best off utilizing either of these resources if you want to run OpenLDAP as a production service on your systems. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by ando＠sys-net.it 07 Sep '07

07 Sep '07

diabeticithink(a)yahoo.com wrote: > Thank you for the help. I cannot upgrade to a later version of OpenLdap > because RHEL 4.0 doesn't support it. Bummer, eh? Well, there is nothing the OpenLDAP project can do for you, then, other than providing more than 3 years of development since 2.2.13 (it was released June 2004), that RedHat in the first place, but basically you seem to be willing to ignore (it's just one click away: untar, configure, make, make install). Or, you should ask RedHat to either upgrade OpenLDAP in RHEL 4.0, or fix your specific bug, if any (I still suspect a misconfiguration, possibly unrelated to OpenLDAP software itself, given that OpenLDAP software does not generate that specific message). As distributors, they are responsible for providing you up-to-date software when available (how responsive they are might depend on the type of maintenance contract you have with them). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by diabeticithink＠yahoo.com 07 Sep '07

07 Sep '07

Thank you for the help. I cannot upgrade to a later version of OpenLdap because RHEL 4.0 doesn't support it. Bummer, eh? -----Original Message----- From: Pierangelo Masarati [mailto:openldap-its@OpenLDAP.org] Sent: Friday, September 07, 2007 2:18 AM To: diabeticithink(a)yahoo.com Cc: openldap-its(a)OpenLDAP.org Subject: Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125) OpenLDAP 2.2.13 is obsolete. Support has been dropped ages ago and even in the case a problem is solved, no new release can occur in that branch. The current release is 2.3.38, so please upgrade and check if the problem persists. In any case, although the error message may appear scaring, there is no indication of a software error, so please direct further discussion to the openldap-software mailing list. This ITS is to track OpenLDAP software bugs, so please don't use it until there's evidence of a software bug. This ITS will be closed. p.

1 0

RE: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125)
by diabeticithink＠yahoo.com 07 Sep '07

07 Sep '07

Yes, it's the OpenLdap software that created this. As soon as I disable the Openldap, the users can change their password without a problem. Any idea on how to fix this? -----Original Message----- From: Kurt Zeilenga [mailto:openldap-its@OpenLDAP.org] Sent: Friday, September 07, 2007 4:10 AM To: diabeticithink(a)yahoo.com Subject: Re: OpenLdap ERROR: passwd: Authentication token manipulation error (ITS#5125) Actually, discussion of this error message should be directed to a mailing list about the LDAP client software, or other software, that actually produced the message. That message doesn't appear to be generated by any OpenLDAP Software.

1 0

Re: (ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 07 Sep '07

07 Sep '07

On Donnerstag, 6. September 2007, ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: > > Hm, current HEAD first calls add_query, which adds the CachedQuery to the > > cache and after that calls cache_entries to add the entries of that Query > > to the cache. That means that query_containment already know about the > > Query before its result is completely cached. > > In RE23 it is just the other way arround (first cache_entries() then > > add_query()). > > I see two possible solution: > > > > 1. Switch back to the old behaviour. But I guess the change was made for > > a reason. I don't know that yet. Seems the change happend between r1.95 > > and r1.96 of pcache.c (log message: "Fix concurrency issues"). > > > > 2. Protect the cached query with an rw_lock. Writelock it while > > cache_entries() is executing and readlock it during searches. This would > > give us the behaviour that Ando suggested in the discussion of ITS#5112. > > (pcache would not try to cache the same search request mulitple times, > > but block the second request until the first one is cached and then > > answer it from the cache) > > +1 (if there's no drawback, of course) The only drawback (if it really is a drawback) is that subsequent clients will have to wait for the caching to be completed. Depending on the query that is being cached can take pretty long. On the other hand one can also view this as an advantage, as it save some network traffic between the proxy that the backend-server. :) -- Ralf

1 0

(ITS#5126) Auto-generation of devel/admin on website
by ghenry＠OpenLDAP.org 07 Sep '07

07 Sep '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, I would like http://www.openldap.org/devel/admin/ to be automatically generated once a week. Daily is too often and might catch a broken make or similar. We can discuss the best time of day to run the job. Thanks, Gavin.

1 0

Re: (ITS#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

ando(a)sys-net.it wrote: > I'll check > if this could also happen with syncrepl, and try to figure out a > workaround. This is now fixed in HEAD and in re23. Please test. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

jclarke(a)linagora.com wrote: > We are using 2.3.37 for both master and slave, and have confirmed that > disactivating the rwm overlay in slapd.conf avoids the problem. The failure is related to the fact that you rewrite the bindDN; this tricks slapo-rwm(5) into failing to recognize that the operation is actually an update, resulting in a double free at cleanup. I'll check if this could also happen with syncrepl, and try to figure out a workaround. In the meanwhile you should be able to solve the problem by reworking the bindDN rewrite rules so that the updatedn is not rewritten. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5124) segfault on modify operation by slurpd with rwm overlay
by ando＠sys-net.it 07 Sep '07

07 Sep '07

jclarke(a)linagora.com wrote: > With a simple master/slave setup, and the rwm overlay activated for the bindDN > context, any modify operation made on the master, replicated with slurpd causes > the slave to crash. > > You will find below a backtrace of the slave when it crashes, and the > configuration files we're using on the master, the slave, an LDIF of the > contents of the directory are in the archive on ftp.openldap.org indicated in > the ITS. > > We are using 2.3.37 for both master and slave, and have confirmed that > disactivating the rwm overlay in slapd.conf avoids the problem. I'll try to look at your report, but let me note that slurpd is deprecated; since you're running OpenLDAP 2.3.37, you're strongly recommended to use syncrepl. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5113) pcache returns incomplete results
by ando＠sys-net.it 06 Sep '07

06 Sep '07

rhafer(a)suse.de wrote: > Hm, current HEAD first calls add_query, which adds the CachedQuery to the > cache and after that calls cache_entries to add the entries of that Query to > the cache. That means that query_containment already know about the Query > before its result is completely cached. > In RE23 it is just the other way arround (first cache_entries() then > add_query()). > I see two possible solution: > > 1. Switch back to the old behaviour. But I guess the change was made for a > reason. I don't know that yet. Seems the change happend between r1.95 and > r1.96 of pcache.c (log message: "Fix concurrency issues"). > > 2. Protect the cached query with an rw_lock. Writelock it while > cache_entries() is executing and readlock it during searches. This would give > us the behaviour that Ando suggested in the discussion of ITS#5112. (pcache > would not try to cache the same search request mulitple times, but block the > second request until the first one is cached and then answer it from the > cache) +1 (if there's no drawback, of course) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5113) pcache returns incomplete results
by rhafer＠suse.de 06 Sep '07

06 Sep '07

On Mittwoch, 29. August 2007, Howard Chu wrote: > rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: HEAD > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.180.39) > > > > > > While the results of a query are being cached, slapo-pcache will answer > > queries that match the same template from the cache that is currently > > being populated. This means that subsequent queries will get incomplete > > results until the original query is completely cached. > > I don't see how that is possible. The query-in-progress isn't added to the > cache until the final result is received. Until then, query_containment > should not know anything is there to answer with. Hm, current HEAD first calls add_query, which adds the CachedQuery to the cache and after that calls cache_entries to add the entries of that Query to the cache. That means that query_containment already know about the Query before its result is completely cached. In RE23 it is just the other way arround (first cache_entries() then add_query()). I see two possible solution: 1. Switch back to the old behaviour. But I guess the change was made for a reason. I don't know that yet. Seems the change happend between r1.95 and r1.96 of pcache.c (log message: "Fix concurrency issues"). 2. Protect the cached query with an rw_lock. Writelock it while cache_entries() is executing and readlock it during searches. This would give us the behaviour that Ando suggested in the discussion of ITS#5112. (pcache would not try to cache the same search request mulitple times, but block the second request until the first one is cached and then answer it from the cache) -- Ralf

1 0

(ITS#5124) segfault on modify operation by slurpd with rwm overlay
by jclarke＠linagora.com 05 Sep '07

05 Sep '07

Full_Name: Jonathan Clarke Version: 2.3.37 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/jclarke-slurpd-rwm-modify-bug.tar.gz Submission from: (NULL) (134.157.159.100) Hello guys, With a simple master/slave setup, and the rwm overlay activated for the bindDN context, any modify operation made on the master, replicated with slurpd causes the slave to crash. You will find below a backtrace of the slave when it crashes, and the configuration files we're using on the master, the slave, an LDIF of the contents of the directory are in the archive on ftp.openldap.org indicated in the ITS. We are using 2.3.37 for both master and slave, and have confirmed that disactivating the rwm overlay in slapd.conf avoids the problem. Thanks in advance for your help ! Jon ***** BACKTRACE ****** conn=0 fd=14 ACCEPT from IP=127.0.0.1:57752 (IP=0.0.0.0:392) [New Thread 32771 (LWP 21187)] conn=0 op=0 BIND dn="uid=replicator,dc=linagora,dc=org" method=128 conn=0 op=0 BIND dn="uid=replicator,dc=linagora,dc=org" mech=SIMPLE ssf=0 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 MOD dn="dc=linagora,dc=org" conn=0 op=1 MOD attr=description entryCSN modifiersName modifyTimestamp conn=0 op=1 RESULT tag=103 err=0 text= Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 21187)] 0x4035dafb in free () from /lib/libc.so.6 (gdb) bt #0 0x4035dafb in free () from /lib/libc.so.6 #1 0x4035f805 in malloc () from /lib/libc.so.6 #2 0x0813e70f in ber_memalloc_x (s=1, ctx=0x40412660) at memory.c:226 #3 0x08079fa8 in ch_malloc (size=16) at ch_malloc.c:54 #4 0x08101567 in rwm_op_modify (op=0x8246fc0, rs=0x6301dce4) at rwm.c:590 #5 0x080b6c5e in overlay_op_walk (op=0x8246fc0, rs=0x6301dce4, which=op_modify, oi=0x81e9688, on=0x81e9778) at backover.c:639 #6 0x080b70ce in over_op_func (op=0x8246fc0, rs=0x6301dce4, which=op_modify) at backover.c:701 #7 0x08077e00 in do_modify (op=0x8246fc0, rs=0x6301dce4) at modify.c:200 #8 0x080609bb in connection_operation (ctx=0x6301dd58, arg_v=0x8246fc0) at connection.c:1133 #9 0x0811a8b4 in ldap_int_thread_pool_wrapper (xpool=0x81d0000) at tpool.c:478 #10 0x402adc51 in pthread_start_thread () from /lib/libpthread.so.0 #11 0x402addb4 in pthread_start_thread_event () from /lib/libpthread.so.0 #12 0x403b438a in clone () from /lib/libc.so.6 ***** End of backtrace *****

1 0

Re: (ITS#5123) slaptest is not checking spelling of keyword access
by ando＠sys-net.it 05 Sep '07

05 Sep '07

lwartha(a)gmail.com wrote: > I made stupid typo and use word acces instead of access in slapd.confl. > Unforutnately slaptest -u does not display any notice about it and display > config file testing succeeded. Because up to 2.3 OpenLDAP didn't care about unrecognized statements. If you run staptest with -dconfig you'll notice warnings (if you're debugging slapd.conf you should; it is not the default because in most cases people are only interested in a yes/no question; ITS#4930 was filed to even remove the "success string"). > > This of cause takes lot of investigation to find it. > > Thanks for fixing it in the future. It's been changed in 2.4 ever since. Now all errors, including unrecognized statements, cause a bailout. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5123) slaptest is not checking spelling of keyword access
by lwartha＠gmail.com 05 Sep '07

05 Sep '07

Full_Name: Ladislav Wartha Version: 2.3.27-4 OS: Fedora Core release 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.122.198.222) Hi, I made stupid typo and use word acces instead of access in slapd.confl. Unforutnately slaptest -u does not display any notice about it and display config file testing succeeded. This of cause takes lot of investigation to find it. Thanks for fixing it in the future. Best regards, Ladislav

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> When slapadd'ing -q, existing database log files seem to become unusable. If >> this is correct, as it seems to be, slapadd could refuse to start with -q if log >> files are present, or, for example, remove the logs if -qq. > > I guess we could add that check. The docs already say that if an error occurs, > the entire database will be unusable. As such, you should only use it for > initially populating a database, not for adding to an existing one. The story is that I placed logs in a separate directory and I forgot to clean them up when regenerating the DB after removing the database files :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5120) slapadd -q makes database logs unusable
by hyc＠symas.com 04 Sep '07

04 Sep '07

ando(a)sys-net.it wrote: > When slapadd'ing -q, existing database log files seem to become unusable. If > this is correct, as it seems to be, slapadd could refuse to start with -q if log > files are present, or, for example, remove the logs if -qq. I guess we could add that check. The docs already say that if an error occurs, the entire database will be unusable. As such, you should only use it for initially populating a database, not for adding to an existing one. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

To reproduce: - set idlcache - search one entry, so that the idl gets cached - delete that entry, so that the idl gets cleared - but head/tail don't - search another entry so that it gets cached - head/tail are corrupted I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure about re23). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5122) back-bdb occasionally allows bogus numeric values
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: since back-config OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando Setting a negative number for cachesize causes an assertion in ch_calloc(); for idlcachesize is just accepted; same for most remaining numeric data. A neat solution would be to define ARG_UINT/ARG_ULONG, redefine types as appropriate (now they're ints, but the negative value has no meaning or causes crash). There seems to be room for 8 more types in the type mask. Not a showstopper, though.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

I noticed that I was intermixing overlay and database configuration statements, but this should be allowed in HEAD. Anyway, I now put configuration statements in the right order, but I've been able to reproduce the problem (not all times, and no devel tools on the maching where I could produce it, except gdb and an unstripped slapd build).... Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5121) IDL cache issue
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux RH AS 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando I ran into an issue running HEAD code. I got the following core dump: #0 0x08103390 in bdb_idl_cache_put (bdb=0xa3e1110, db=0x3550c800, key=0x35f988a0, ids=0x34afc008, rc=0) at ../../../../servers/slapd/back-bdb/idl.c:354 #1 0x08104318 in bdb_idl_fetch_key (be=0x36058ec0, db=0x3550c800, locker=0, key=0x35f988a0, ids=0x34afc008, saved_cursor=0x0, get_flag=0) at ../../../../servers/slapd/back-bdb/idl.c:665 #2 0x081084a1 in bdb_key_read (be=0x36058ec0, db=0x3550c800, locker=100, k=0x352ff2d4, ids=0x34afc008, saved_cursor=0x0, get_flag=0) at ../../../../servers/slapd/back-bdb/key.c:50 #3 0x081013ab in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x352ff2c4, ids=0x34bfc008, tmp=0x34afc008, stack=0x34c7c008) at ../../../../servers/slapd/back-bdb/filterindex.c:770 #4 0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98dd0, ftype=161, ids=0x34b7c008, tmp=0x34afc008, save=0x34bfc008) at ../../../../servers/slapd/back-bdb/filterindex.c:580 #5 0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x35f98dc0, ids=0x34b7c008, tmp=0x34afc008, stack=0x34bfc008) at ../../../../servers/slapd/back-bdb/filterindex.c:204 #6 0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98db0, ftype=160, ids=0x35fd8e30, tmp=0x34afc008, save=0x34b7c008) at ../../../../servers/slapd/back-bdb/filterindex.c:580 #7 0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, f=0x35f98de0, ids=0x35fd8e30, tmp=0x34afc008, stack=0x34b7c008) #8 0x081109b5 in bdb_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../../servers/slapd/back-bdb/search.c:1111 #9 0x080ee601 in overlay_op_walk (op=0xa46b3f8, rs=0x3605a0f0, which=op_search, oi=0xa3e21e0, on=0xa3e2740) at ../../../servers/slapd/backover.c:652 #10 0x080ee72f in over_op_func (op=0xa46b3f8, rs=0x3605a0f0, which=op_bind) at ../../../servers/slapd/backover.c:704 #11 0x0808a051 in fe_op_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../servers/slapd/search.c:368 #12 0x080894f7 in do_search (op=0xa46b3f8, rs=0x3605a0f0) at ../../../servers/slapd/search.c:217 #13 0x080875c3 in connection_operation (ctx=0x3605a210, arg_v=0xa46b3f8) at ../../../servers/slapd/connection.c:1145 #14 0x0808801b in connection_read_thread (ctx=0x3605a210, argv=0x14) at ../../../servers/slapd/connection.c:1271 #15 0x081afa01 in ldap_int_thread_pool_wrapper (xpool=0xa304fa8) at ../../../libraries/libldap_r/tpool.c:614 #16 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 #17 0x00736c3e in clone () from /lib/tls/libc.so.6 where (gdb) p bdb->bi_idl_cache_max_size $27 = 30000 (gdb) p bdb->bi_idl_lru_head $28 = (bdb_idl_cache_entry_t *) 0x3550cd28 (gdb) p bdb->bi_idl_lru_tail $29 = (bdb_idl_cache_entry_t *) 0x3550cd28 (gdb) p bdb->bi_idl_lru_tail[0] $30 = {kstr = {bv_len = 3, bv_val = 0x3550ebd8 "top"}, idl = 0x6, db = 0x3550ebe8, idl_flags = 0, idl_lru_prev = 0x0, idl_lru_next = 0x0} The latter seems quite odd: obviously the head/tail is corrupted, but either bdb->bi_idl_lru_tail and bdb->bi_idl_lru_head should be null, or their idl_lru_prev and idl_lru_next members should be valid. There seems to be something odd in how entries are cleaned up from the cache: in fact, if the whole LRU is destroyed, then eprev would remain dangling, but this should never occur. p.

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

BTW, I'm currently using Berkeley 4.2.52 w/ patches w/ HEAD code, if it matters. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 04 Sep '07

04 Sep '07

Full_Name: Pierangelo Masarati Version: all supporting -q OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando When slapadd'ing -q, existing database log files seem to become unusable. If this is correct, as it seems to be, slapadd could refuse to start with -q if log files are present, or, for example, remove the logs if -qq. p.

1 0

ITS#3636 more flexible file: URLs in LDIFs
by hyc＠symas.com 04 Sep '07

04 Sep '07

Some notes... Most of the forms in the original request have been supported in 2.3/2.4/HEAD for a long time, I just didn't remember this ITS existed. It has some bearing on #5117 as well. Specifically file:/absolute/path file:relative/path file:simple.name are allowed (but deprecated) by RFC 3986 and are supported. (RFC1808 and 3986 expect relative URLs to have no scheme specifier at all. We don't handle that case. We also don't handle file://localhost/absolute/path and probably should.) file://simple.name violates RFC3986 and is rejected. The latest draft spec for FILE URIs has died, and it looks like it was plagued with too many strange behaviors to formulate a coherent spec. http://tools.ietf.org/html/draft-hoffman-file-uri-03 http://offset.skew.org/wiki/URI/File_scheme/Plan_of_action In the meantime, the libcurl API is a lot more complicated than libfetch. Might be nice to have, but it will not be as straightforward... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5119) double free in slapd
by hyc＠symas.com 04 Sep '07

04 Sep '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.38/RE23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > There is apparently a bug in attribute normalization of objectClasses that can > result in a double free in slapd, causing it to crash. My mistake, not a double-free. Fixed in HEAD/RE23/RE24. > Please see: > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440632> > > This behavior still exists in current RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5119) double free in slapd
by quanah＠zimbra.com 04 Sep '07

04 Sep '07

Full_Name: Quanah Gibson-Mount Version: 2.3.38/RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) There is apparently a bug in attribute normalization of objectClasses that can result in a double free in slapd, causing it to crash. Please see: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440632> This behavior still exists in current RE23. --Quanah

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs