openldap-bugs July 2007

openldap-bugs@openldap.org

30 participants
126 discussions

(ITS#5051) Translucent overlay and back-monitor
by ghenry＠OpenLDAP.org 19 Jul '07

19 Jul '07

Full_Name: Gavin Henry Version: 19/07/07 HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear All, Is slapd not started and giving below expected? ================ monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": unable to find entry backend_startup_one: bi_db_open failed! (1) slapd shutdown: initiated ================ Using a config like: ================ include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload translucent.la database bdb directory /usr/local/var/openldap-data cachesize 10000 suffix "dc=suretecsystems,dc=com" rootdn "cn=admin,dc=suretecsystems,dc=com" rootpw {SSHA}blah index default eq index objectClass,uid,dc,o,ou overlay translucent uri ldap://x.x.x.x:389 idassert-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials=blah database config rootdn "cn=config" rootpw {SSHA}blah database monitor ================ If I remove "database monitor", all is obviously well. However, if I put "database monitor" before "database bdb", slapd starts fine, but complains with: ================ monitor_back_register_entry_parent(""): base="cn=databases,cn=monitor" scope=subordinate filter="(&(monitoredInfo=ldap)(!(monitorOverlay=ldap))(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com))": unable to find entry slapd starting ================ Gavin.

1 0

(ITS#5050) array bounds violation in test045-syncreplication-proxied
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard syncprov + back-ldap, and presumably + back-meta if that were used, give an array bounds violation in test045-syncreplication-proxied: syncprov_db_open() uses connection_fake_init(), which sets op->o_tag=0. It passes op to back-ldap. ldap_back_op_result() assumes op is a known LDAP request: It calls slap_req2op() and gets SLAP_OP_LAST (for unknown tag). That is used as an index into ldapinfo_t.li_timeout[], which has size SLAP_OP_LAST. back-meta/bind.c does the same in meta_back_bind_op_result() and meta_back_op_result(). HEAD backtrace, from an assert(0) I put in slap_req2op(): #3 0x003d8d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0809ac0e in slap_req2op (tag=0) at operation.c:203 #5 0x0816dba8 in ldap_back_op_result (lc=0x83a12f8, op=0xbfffe948, rs=0xbfffe70c, msgid=1, timeout=-1, sendok=20) at bind.c:1582 #6 0x0816d727 in ldap_back_dobind_int (lcp=0xbfffe760, op=0xbfffe948, rs=0xbfffe70c, sendok=LDAP_BACK_GETCONN, retries=0, dolock=1) at bind.c:1411 #7 0x0816d814 in ldap_back_dobind (lcp=0xbfffe760, op=0xbfffe948, rs=0xbfffe70c, sendok=LDAP_BACK_DONTSEND) at bind.c:1440 #8 0x0812921a in ldap_back_entry_get (op=0xbfffe948, ndn=0x833b2a8, oc=0x0, at=0x82ec610, rw=0, ent=0xbfffe944) at search.c:790 #9 0x080f7a55 in overlay_entry_get_ov (op=0xbfffe948, dn=0x833b2a8, oc=0x0, ad=0x82ec610, rw=0, e=0xbfffe944, on=0x0) at backover.c:365 #10 0x081bd9da in syncprov_db_open (be=0x833a8a0) at syncprov.c:2550 #11 0x080f70b2 in over_db_func (be=0x833a8a0, which=db_open) at backover.c:61 #12 0x080f74c9 in over_db_open (be=0x833a8a0) at backover.c:174 #13 0x08092515 in backend_startup_one (be=0x833a8a0) at backend.c:212 #14 0x080929a2 in backend_startup (be=0x833a8a0) at backend.c:303 #15 0x080b9a94 in slap_startup (be=0x0) at init.c:243 #16 0x0806719d in main (argc=8, argv=0xbfffef14) at main.c:919

1 0

(ITS#5049) uninitialized Connection in syncprov
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard syncprov_db_close() does not initialize 'conn' before passing it to connection_fake_init(). (That function is a bit misnamed - the passed connection must be initialized, but not the passed operation.) Fixing in HEAD. Is RE23 frozen now?

1 0

(ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 18 Jul '07

18 Jul '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. findcsn_cb() says /* We just want to know that at least one exists, so it's OK if * we exceed the unchecked limit or size limit. */ This looks like it can return a false positive if two or more other entries which the filter would eliminate have the same hash as the value syncprov searches for. Also syncprov_findcsn() passes fc_limits uninitialized outside of the .lms_s_unchecked field to slapd. Valgrind complains in test018 about .lms_s_pr_hide in back-bdb/search.c:bdb_search(). Tested in HEAD.

1 0

(ITS#5046) ITS auto-reply and copyright date
by ghenry＠OpenLDAP.org 14 Jul '07

14 Jul '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry ITS auto-reply needs updating: "Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved."

1 0

(ITS#5045) collect.c and Dynamic Config
by ghenry＠OpenLDAP.org 14 Jul '07

14 Jul '07

Full_Name: Gavin Henry Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, I think if collect.c is still to be used as demonstration of overlay code in 2.4, then it needs some of the usual ConfigDriver/ConfigTable/ConfigOCs stuff. Would be useful for new contributors etc. Saying that, there is no harm in others reviewing existing overlays. Just some thoughts. Gavin.

1 0

Re: (ITS#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by h.b.furuseth＠usit.uio.no 13 Jul '07

13 Jul '07

Do you use "database ldbm" in slapd.conf? The LDAP Compare operation can make it crash that way. (Since OpenLDAP 2.3.16; back-ldbm/compare.c rev 1.53.) I've committed a fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/Attic/comp… BDB more reliable. LDBM has been removed in OpenLDAP 2.4. -- Regards, Hallvard

1 0

Re: (ITS#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by hyc＠symas.com 13 Jul '07

13 Jul '07

alexander.kasper(a)ruhr-uni-bochum.de wrote: > Full_Name: Alexander Kasper > Version: @(#) $OpenLDAP: slapd 2.3.36 (Jul 6 2007 14:15:37) $ > OS: Linux version 2.6.18-xendomU (root@localhost) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (134.147.48.236) > > > I cannot clearly reproduce the error/assert > > slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= > 0' failed > > since the slapd dies randomly. I'm runnig it on a virtual xen userDomain in > 64Bit mode. > > plz tell me, which debug-level would be fine, since -d 65535 produce 10MB output > for one search, and as i said slapd dies randomly. There are reports that Xen does not properly support mutexes. As such, it cannot be used to run slapd. http://www.openldap.org/lists/openldap-software/200603/msg00207.html -- -- 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#5044) slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed
by alexander.kasper＠ruhr-uni-bochum.de 13 Jul '07

13 Jul '07

Full_Name: Alexander Kasper Version: @(#) $OpenLDAP: slapd 2.3.36 (Jul 6 2007 14:15:37) $ OS: Linux version 2.6.18-xendomU (root@localhost) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.147.48.236) I cannot clearly reproduce the error/assert slapd: rdwr.c:256: ldap_pvt_thread_rdwr_runlock: Assertion `rw->ltrw_r_active >= 0' failed since the slapd dies randomly. I'm runnig it on a virtual xen userDomain in 64Bit mode. plz tell me, which debug-level would be fine, since -d 65535 produce 10MB output for one search, and as i said slapd dies randomly. greets Alex

1 0

Re: (ITS#5028) incomplete slapcat docs
by ghenry＠suretecsystems.com 13 Jul '07

13 Jul '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="h.b.furuseth(a)usit.uio.no"> >> hyc(a)symas.com writes: >>> steve(a)stevenwills.com wrote: >>>> The slapcat man page says in the Limitations section: >>>> >>>> In general, your slapd(8) should not be running (at least, not >>>> in >>>> read-write mode) when you do this to ensure consistency of the >>>> database. >>>> (...) >>> Given that back-ldbm has been deleted for 2.4, I guess we can just >>> delete this sentence. >> >> It could produce garbage data with back-ldif, and with some foreign >> database module. I think it should say it's safe with bdb (and null). >> Could copy it to the slapd-bdb(5) too. (I don't suggest to make >> slapcat(8) refer the user to that, since there is only one example >> anyway.) > > Obviously hdb too. Would it produce garbage on 2.4? Do we want to do anything with this for .37? > >> >> -- >> Regards, >> Hallvard >> >> >> > > >

1 0

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2007