openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

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

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

------=_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. 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#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 30 Nov '06

30 Nov '06

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

1 0

Re: (ITS#4763) slapd crashed with ldapsearch command without arguments
by hyc＠symas.com 30 Nov '06

30 Nov '06

Since it appears that you're using BerkeleyDB 4.5 which is not the default version installed on your platform, most likely you have conflicting libdb libraries loaded. If you're using the default libsasl2, then this is certainly the problem. You can find out for sure by running slapd under gdb. When it crashes use the command "info shared" to see what shared libraries are present. If you see two different versions of libdb, that's your problem. You'll need to rebuild whatever other libraries are using the other libdb version and get everything onto the same version. At any rate, I don't believe there's any bug in OpenLDAP software here. This ITS will be closed. saint.cn(a)gmail.com wrote: > Full_Name: Jack Chen > Version: 2.3.27 > OS: Redhat AS 3.0 2.4.21-40.ELsmp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.12.9.18) > > > I found when I run ldap commands without arguments always get password imput > requirement before result. But the command always told me > "ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the > slapd crashed. > > Then I start slpad with command like "slpad -d 256" with root account and want > to get debug information before slpad crash. > > Then following is the startup information: > ===================================================================== > @(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $ > root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd > daemon: IPv6 socket() failed errno=97 (Address family not supported by > protocol) > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: Warning - No DB_CONFIG file found in directory > /usr/local/openldap/var/openldap-data: (2) > Expect poor performance for suffix dc=test,dc=com. > slapd starting > ===================================================================== > > And when I input command "ldapsearch" in shell with root account, and input > password with any words and return. The command tell me like following: > ===================================================================== > /usr/local/BerkeleyDB.4.5/bin:$ldapsearch > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > ===================================================================== > > And I check the console which is running slapd, and get following information: > ===================================================================== > conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389) > conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > conn=0 op=0 SRCH attr=supportedSASLMechanisms > conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=0 op=1 BIND dn="" method=163 > conn=0 op=1 RESULT tag=97 err=14 text= > conn=0 op=2 BIND dn="" method=163 > /etc/sasldb2: Successful return: 0 > segment fault (core dumped) > ===================================================================== -- -- 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 hyc＠symas.com 30 Nov '06

30 Nov '06

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/

1 0

(ITS#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

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?

1 0

(ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

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 ...

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 29 Nov '06

29 Nov '06

Aaron Richton wrote: > Actually, this could be it exactly. To my reading, the 0.9.8d tarball > still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses > CRYPTO_set_id_callback. And the most recent thread I see on the matter > ended > (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with > an attitude of "Yeah, if anything, we should make things break more > frequently when there's no callback set." Perhaps we should be adding > one, with a bit of platform awareness through lutil? In the current OpenSSL, the address of errno is tested as well. Since this is always unique per thread, there's really no need to set the id callback any more. The problem with just using CRYPTO_set_id_callback is that it doesn't work on platforms where a thread ID is not an integer (e.g. OS/390). I don't think CRYPTO_set_idptr_callback was available in earlier OpenSSL releases. Too bad they didn't define CRYPTO_set_id_callback correctly, to return the actual type of a thread ID instead of unsigned long. > > On Wed, 29 Nov 2006, Howard Chu wrote: > >> Aaron Richton wrote: >>> I'm on latest 0.9.7 release. I can try and put together a slapd with >>> 0.9.8d, and I guess if we're going to (potentially?) be pointing >>> fingers toward OpenSSL that's a good idea anyway... >> >> Yes, definitely a good idea. The prior releases always used getpid() >> to determine the threadID of the current thread, to decide if locking >> was needed. This is obviously only correct on old systems running >> LinuxThreads, where each thread was actually a separate process. It's >> surprising that it wasn't until recently that we've started seeing >> crashes caused by this bug. > > . > -- -- 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#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 29 Nov '06

29 Nov '06

Actually, this could be it exactly. To my reading, the 0.9.8d tarball still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses CRYPTO_set_id_callback. And the most recent thread I see on the matter ended (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with an attitude of "Yeah, if anything, we should make things break more frequently when there's no callback set." Perhaps we should be adding one, with a bit of platform awareness through lutil? On Wed, 29 Nov 2006, Howard Chu wrote: > Aaron Richton wrote: >> I'm on latest 0.9.7 release. I can try and put together a slapd with >> 0.9.8d, and I guess if we're going to (potentially?) be pointing fingers >> toward OpenSSL that's a good idea anyway... > > Yes, definitely a good idea. The prior releases always used getpid() to > determine the threadID of the current thread, to decide if locking was > needed. This is obviously only correct on old systems running LinuxThreads, > where each thread was actually a separate process. It's surprising that it > wasn't until recently that we've started seeing crashes caused by this bug.

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