openldap-bugs September 2007

openldap-bugs@openldap.org

33 participants
179 discussions

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 03 Sep '07

03 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2007