openldap-bugs August 2010

openldap-bugs@openldap.org

23 participants
68 discussions

Re: (ITS#6623) segmentation fault
by michael＠stroeder.com 16 Aug '10

16 Aug '10

nareshyathapu(a)gmail.com wrote: > Full_Name: Naresh Reddy > Version: 2.4.11 Current release is 2.4.23. There have been a lot of changes since then including fixes for crashes. So if you suspect OpenLDAP server software to crash could you please try to reproduce this with the current release? > Trying to connect to ldapserver and ldap server is down. Core dump is happening > below is the code and gdb.. Is slapd crashing? > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at > ffffe0b4 > Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Could you please elaborate on what kind of software /usr/UMR/current/bin/ldapMgr is? I'm not a OpenLDAP core developer but that does not look like an OpenLDAP component to me. Ciao, Michael.

1 0

(ITS#6623) segmentation fault
by nareshyathapu＠gmail.com 16 Aug '10

16 Aug '10

Full_Name: Naresh Reddy Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.166.63.98) Trying to connect to ldapserver and ldap server is down. Core dump is happening below is the code and gdb.. Code ------- u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } GDB ----- warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Program terminated with signal 11, Segmentation fault. #0 0x43b91cc9 in free () from /lib/libc.so.6 (gdb) bt #0 0x43b91cc9 in free () from /lib/libc.so.6 #1 0x080a6854 in ldap_free_select_info (sip=0x118) at os-ip.c:936 #2 0x080a29ab in ldap_ld_free (ld=0xf3ebec20, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:131 #3 0x080a2aab in ldap_unbind_ext (ld=0xf3ebec20, sctrls=0x0, cctrls=0x0) at unbind.c:52 #4 0x0808368f in LdapConnection::connect (this=0xd252888, loginDN=0xd258ddc "bwLoginname=sms_ldap_bind", pwd=0xd258edd "metropcs_sms") at LdapConnection.cpp:159 #5 0x08051731 in LdapPeer::LdapWorkerProcess (this=0xd2586b0) at LdapPeer.cpp:322 #6 0x080827b2 in run (handle=0xd2586b0) at LdapCommonDefs.cpp:47 #7 0x43c5be49 in ?? () from /lib/libpthread.so.0

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

Doug Leavitt wrote: > I have been testing pretty consistently on Solaris this year, > most recent on HEAD versus RELEASE. thats how I noticed > the ITS 6621 issue. > > I may be able to do some specific testing on specific hardware > platforms, depending on what is desired, and what I can get > access to. I do regulary test on both x86 and sparc platforms. > > Also, I now have Oracle legal permission to pass OpenLDAP > enhancements and fixes upstream. > > I am almost ready to submit a proposed patch to libldap to deliver > a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt > functionality for OpenLDAP libldap. > > My proposed patch so far implements the ldap_dup and > ldap_destroy portions of the specification, but I have not > yet implemented the LDAP_OPT_SESSION_REFCNT or > added any LDAP_API_FEATURE* style macros. > > I would like some guidance if/what macros in ldap.h are desired. > > I am working on the assumption that some public discussion > and peer review will be expected before any patch submission > would be accepted. > > Should I start with a discussion on openldap-technical first? Other? Sounds very interesting; discussions of this nature (modifications to OpenLDAP code) are most appropriate for the -devel list. Looking forward to continuing this conversation there. > > Doug. > > > > On 08/12/10 06:21 PM, hyc(a)symas.com wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? >> > -- -- Howard Chu CTO, 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#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

I have been testing pretty consistently on Solaris this year, most recent on HEAD versus RELEASE. thats how I noticed the ITS 6621 issue. I may be able to do some specific testing on specific hardware platforms, depending on what is desired, and what I can get access to. I do regulary test on both x86 and sparc platforms. Also, I now have Oracle legal permission to pass OpenLDAP enhancements and fixes upstream. I am almost ready to submit a proposed patch to libldap to deliver a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt functionality for OpenLDAP libldap. My proposed patch so far implements the ldap_dup and ldap_destroy portions of the specification, but I have not yet implemented the LDAP_OPT_SESSION_REFCNT or added any LDAP_API_FEATURE* style macros. I would like some guidance if/what macros in ldap.h are desired. I am working on the assumption that some public discussion and peer review will be expected before any patch submission would be accepted. Should I start with a discussion on openldap-technical first? Other? Doug. On 08/12/10 06:21 PM, hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? >

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? > > I haven't had access to Solaris in years... p. Me neither. Too bad, a Niagara might actually show more than a 1% gain from the multi-listener patch. -- -- Howard Chu CTO, 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? I haven't had access to Solaris in years... p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: > Blind-fixed in HEAD. Thanks, p. By the way Ando, any more ideas about the devpoll implementation? Have you tested it against select on Solaris recently? -- -- Howard Chu CTO, 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Blind-fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) > > > Two syntax errors were introduced into daemon.c as a result of: > the commits to change daemon.c 1.444 -> 1.445 -> 1.446 > > > Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. > > > --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 > +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 > @@ -521,7 +521,7 @@ > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > int i; \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > for ( i=0; i<readfds.fd_count; i++) { \ > int fd = slapd_sock2fd(readfds.fd_array[i]); \ > @@ -666,7 +666,7 @@ > # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd),&writefds) > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > } while (0) > # endif /* !HAVE_WINSOCK */ > > Nice catch, thanks. -- -- Howard Chu CTO, 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#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1000000000 with a parent of > 9999999999 (and > a row 9999999999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1410065407 = 32-bit rollover of 9999999999). A (blind) fix is in HEAD; you need to pull modifications related to this ITS and to ITS#6622. Please test and report. p.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2010