openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Start a nNew thread

Re: (ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Seems to be ok now (synced HEAD). Ciao, Michael.

1 0

(ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 04 Dec '06

04 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.87) [..] Testing add: valid local record... Testing search: data merging... Testing compare: valid local... Testing compare: valid remote... Testing compare: bogus local... Testing compare: bogus remote... Testing modify: nonexistent record... Testing modify: valid local record, nonexistent attribute... Testing search: specific nonexistent remote attribute... Testing modify: nonexistent local record, nonexistent attribute... ./scripts/test034-translucent: line 369: 9807 Segmentation fault $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >$LOG2 2>&1 ldapsearch failed (255)! ./scripts/test034-translucent: line 384: kill: (9807) - No such process ------------------------------------------------------------------------- last lines of testrun/slapd.2.log => bdb_entry_get: ndn: "uid=fred,ou=users,o=translucent" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => translucent_modify: fabricating local add => glue_parent: fabricating glue for <ou=users,o=translucent> ==> bdb_add: o=translucent bdb_dn2entry("o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: ou=users,o=translucent bdb_dn2entry("ou=users,o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: uid=fred,ou=users,o=translucent is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => bdb_dn2id_add( "uid=fred,ou=users,o=translucent", 0x00000007 ) bdb_idl_insert_key: 7 %ou=users,o=translucent bdb_idl_insert_key: 7 @ou=users,o=translucent <= bdb_dn2id_add: 0 => index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) <= index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) success => entry_encode(0x00000007): uid=fred,ou=users,o=translucent bdb_add: added id=00000007 dn="uid=fred,ou=users,o=translucent" send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=103 err=0 ber_flush2: 14 bytes to sd 12

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 03 Dec '06

03 Dec '06

1 0

Re: (ITS#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

ando(a)sys-net.it wrote: > I've added optional normalization code as appropriate. > Fixed in HEAD/re23. It impacts all occurrences of bindconf_parse(), including syncrepl consumer side configuration, whenever an incorrect DN value is used as binddn, or an incorrect identity is used for authcid/authzid. p.

1 0

(ITS#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando I've added optional normalization code as appropriate. p.

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Kurt(a)OpenLDAP.org wrote: > At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: > >> ------=_Part_1103_3773705.1164959961858 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> oh, not compiler. but at runtime the daemon will output this during >> initialization: >> ... >> slap_schema_load: AttributeType "ditStructureRules": not defined in schema >> ... >> I tested this on some mainframe. case difference does matter. when i changed >> the case, it ran ok. >> > > Seems like strcasecmp(3) routines are not ignoring case as they should. > I've made the case of those strings conform to how they're indicated in the related RFC, although attribute names MUST be case insensitive. This solves your problem in the short term, but you should really look at that strcasecmp(3) issue. p.

1 0

OpenLDAP crash on write operation with syncprov overlay enabled
by Alexandre Biancalana 01 Dec '06

01 Dec '06

Hi list, I'm migration an OpenLDAP server from Debian linux to FreeBSD 6-STABLE. I exported the database from old server with slapcat and impoted at Free without any problems. But when I enable syncprov overlay and do any write operation (ie.: ldapmodify) on the base the OpenLDAP crash with signal 11. I tested with FreeBSD 6-STABLE (cvsuped sources yesterday), FreeBSD 5-STABLE (cvsuped one month ago) with OpenLDAP 2.3 and 2.4 installed through ports and packages, on diferent machines PIII SMP, Semprom UP, Centrino UP, P4 UP. The problem just ocurs when the syncprov overlay is enabled. Trying to debug this I run slapd through gdb: Pink:/usr/local/etc/openldap # gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run -u ldap -g ldap -d 1 Starting program: /usr/local/libexec/slapd -u ldap -g ldap -d 1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ .(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 3 (LWP 100229)] 0x0807f954 in fe_op_abandon () (gdb) bt #0 0x0807f954 in fe_op_abandon () #1 0x0807f957 in fe_op_abandon () #2 0x0807f957 in fe_op_abandon () #3 0x0807f957 in fe_op_abandon () #4 0x0807f957 in fe_op_abandon () #5 0x0807f957 in fe_op_abandon () #6 0x0807f957 in fe_op_abandon () #7 0x0807f957 in fe_op_abandon () #8 0x0807f957 in fe_op_abandon () #9 0x0807f957 in fe_op_abandon () #10 0x0807f957 in fe_op_abandon () #11 0x0807f957 in fe_op_abandon () #12 0x0807f957 in fe_op_abandon () #13 0x0807f957 in fe_op_abandon () #14 0x0807f957 in fe_op_abandon () #15 0x0807f957 in fe_op_abandon () #16 0x0807f957 in fe_op_abandon () #17 0x0807f957 in fe_op_abandon () #18 0x0807f957 in fe_op_abandon () #19 0x0807f957 in fe_op_abandon () #20 0x0807f957 in fe_op_abandon () #21 0x0807f957 in fe_op_abandon () #22 0x0807f957 in fe_op_abandon () #23 0x0807f957 in fe_op_abandon () #24 0x0807f957 in fe_op_abandon () #25 0x0807f957 in fe_op_abandon () #26 0x0807f957 in fe_op_abandon () #27 0x0807f957 in fe_op_abandon () #28 0x0807f957 in fe_op_abandon () .... #29406 0x0807f957 in fe_op_abandon () #29407 0x0807f957 in fe_op_abandon () #29408 0x0807f957 in fe_op_abandon () ^^^^^^^^^ ---> This look's like never end..... Follow my slapd.conf: ============================ include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/samba.schema loglevel 1 8 16 256 512 16384 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/local/libexec/openldap moduleload back_hdb sizelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth database hdb suffix "dc=company,dc=com" rootdn "cn=root,dc=company,dc=com" rootpw my_secret_password directory /var/db/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub index entryCSN eq index entryUUID eq I'm very pleased to someone that could help me to figure out where is the problem.... Best Regards, Alexandre Biancalana

2 2

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 01 Dec '06

01 Dec '06

At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >------=_Part_1103_3773705.1164959961858 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during >initialization: >... >slap_schema_load: AttributeType "ditStructureRules": not defined in schema >... >I tested this on some mainframe. case difference does matter. when i changed >the case, it ran ok. Seems like strcasecmp(3) routines are not ignoring case as they should. >On 12/1/06, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: >> >> At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >> >Full_Name: Gang Wang >> >Version: 2.3.20 >> >OS: >> >URL: ftp://ftp.openldap.org/incoming/ >> >Submission from: (NULL) (202.108.130.138) >> > >> > >> >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 >> > >> > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " >> > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " >> > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " >> > >> >there are some "dIT" in the strings instead of "dit". is it some kind of >> typo >> >error? I'm porting this version to some operating system. the compiler >> complains >> >... >> >> About the case difference in these strings? I doubt that. >> >> Kurt >> >> > >------=_Part_1103_3773705.1164959961858 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. > <div>On 12/1/06, Kurt D. Zeilenga <<a href="mailto:Kurt@openldap.org">Kurt(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >At 10:32 PM 11/30/2006, <a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/ ></a> >Submission from: (NULL) (<a href="http://202.108.130.138">202.108.130.138</a>) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > >        "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > >        { "ditStructureRules", "( <a href="http://2.5.21.1">2.5.21.1</a> NAME 'dITStructureRules' " >        { "ditContentRules", "( <a href="http://2.5.21.2">2.5.21.2</a> NAME 'dITContentRules' " > > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error?  I'm porting this version to some operating system. the compiler complains >... >About the case difference in these strings?  I doubt that. Kurt </blockquote></div> > >------=_Part_1103_3773705.1164959961858--

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 01 Dec '06

01 Dec '06

Gang Wang wrote: > Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. > You are assuming the semantics of FD_ZERO() is to "set something as > zero", but on some system it is not. For example, implement fd_set as an > array, then 0 is a valid value. FD_ZERO() have to initialize something > as -1 ... > Funny that the code treat sd_actives differently. That's a different question than you asked at first. > BTW, I know C spec well. Then you should know your original question has no dependency on the compiler being used. Rather than waste people's time, you should ask your actual question at the outset, not some meaningless one. > > On 12/1/06, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > wanggang.wang(a)gmail.com <mailto:wanggang.wang@gmail.com> wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) ( 202.108.130.138 <http://202.108.130.138>) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

------=_Part_1433_15850837.1164961653601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. On 12/1/06, Howard Chu <hyc(a)symas.com> wrote: > > wanggang.wang(a)gmail.com wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (202.108.130.138) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? > > It is a basic part of the C language specification - variables declared > at file scope are implicitly initialized to zero. Perhaps you need to > study the language a bit more before trying to do any more work in it. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > ------=_Part_1433_15850837.1164961653601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. <div>On 12/1/06, Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: > Full_Name: Gang Wang > Version: 2.3.20 > OS: > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://202.108.130.138"> 202.108.130.138</a>) > > > openldap-2.3.20/servers/slapd/daemon.c > > There is one declaration in slap_daemon structure: > >     fd_set sd_actives; > > this variable is not initialized ... is this OK with all compilers? It is a basic part of the C language specification - variables declared at file scope are implicitly initialized to zero. Perhaps you need to study the language a bit more before trying to do any more work in it. --    -- Howard Chu    Chief Architect, Symas Corp.  <a href="http://www.symas.com">http://www.symas.com</a>    Director, Highland Sun        <a href="http://highlandsun.com/hyc">http://highlandsun.com/hyc </a>    OpenLDAP Core Team            <a href="http://www.openldap.org/project/">http://www.openldap.org/project/</a> </blockquote></div> ------=_Part_1433_15850837.1164961653601--

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