openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6448) BUS Error on Multi Master Mode
by acirulli＠gmail.com 12 Jan '10

12 Jan '10

Full_Name: Andrea Cirulli Version: 2.4.21 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.77.56.181) Hi, I have setted up two multimasters in mirror mode. After launching in debug mode with -d 16384 once I stop the slapd ( by CTRL+c ) I obtain a bus error. below the analysis of the core: [New Thread 1 (LWP 1)] Loaded symbols for /usr/lib/64//libthread.so.1 warning: Can't read pathname for load map: I/O error. warning: Can't read pathname for load map: I/O error. Core was generated by `libexec/slapd -f etc/openldap/slapd.conf -h ldap://:379 -d 16384'. Program terminated with signal 10, Bus error. #0 0x00000001001fb8f4 in avl_free () (gdb) thread apply all bt full Thread 2 (Thread 1 (LWP 1)): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (LWP 1 ): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?)

1 0

RE: (ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by Biren.Patel＠directbrands.com 11 Jan '10

11 Jan '10

Please close this issue, it has been resolved. Thanks -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Monday, January 11, 2010 10:31 AM To: Patel, Biren - Direct Brands Subject: Re: (ITS#6447) Can't compile openldap with --enable-dynamic on so= lari sparc 10 *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6447. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6447) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#6447) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6447 Please remember to retain your issue tracking number (ITS#6447) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by michael＠stroeder.com 11 Jan '10

11 Jan '10

j(a)gropefruit.com wrote: > Please clarify this statement in your 2.5 roadmap: Any reason why you didn't simply post this to the openldap-software mailing list? > LDAPv3 extensions: > *LDAP Transaction support AFAIK this means implementing draft-zeilenga-ldap-txn http://tools.ietf.org/draft/draft-zeilenga-ldap-txn/ Ciao, Michael.

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by quanah＠zimbra.com 11 Jan '10

11 Jan '10

--On Wednesday, January 06, 2010 11:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny-AMD64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.67.92.30) > > > Please clarify this statement in your 2.5 roadmap: This is not a bug report. If you have development questions, please send them to openldap-devel(a)openldap.org for discussion. Thanks! This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by biren.patel＠directbrands.com 11 Jan '10

11 Jan '10

Full_Name: Biren Patel Version: openldap-2.4.19 OS: SPARC Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.223.34.13) I can't compile openldap with option --enable-dynamic on SPARC Solaris 10. Receiving the error provided below. It complies fine without the --enable-dynamic but when complie PHP 5 with ldap, PHP gives me the same error. I have norrowed down to Openldap not able to compile all the libs as dynamic loadable. Please help Using gcc. Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 /bin/sh ../../libtool --mode=link gcc -D_AVL_H -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ -R/usr/local/BerkeleyDB/lib -R/usr/local/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket gcc -D_AVL_H -o .libs/apitest apitest.o -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ ./.libs/libldap.so /u/bpatel/openldap-2.4.21/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket -Wl,--rpath -Wl,/usr/local/openldap/lib -Wl,--rpath -Wl,/usr/local/BerkeleyDB/lib -Wl,--rpath -Wl,/usr/local/lib /usr/ccs/bin/ld: ./.libs/libldap.so: dlclose: invalid version 13 (max 0) ./.libs/libldap.so: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6446) Quickstart guide only uses slapd.conf
by gavin.henry＠gmail.com 07 Jan '10

07 Jan '10

Will update. Thanks! On 07/01/2010, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The quickstart guide on the OpenLDAP home page only references using > slapd.conf. > It has no references to the new config backend. Since slapd.conf is > deprecated, it would be good to have a quickstart guide that reflected this. > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6446) Quickstart guide only uses slapd.conf
by quanah＠OpenLDAP.org 07 Jan '10

07 Jan '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The quickstart guide on the OpenLDAP home page only references using slapd.conf. It has no references to the new config backend. Since slapd.conf is deprecated, it would be good to have a quickstart guide that reflected this.

1 0

(ITS#6445) Duplicate free with back-relay + passwd op
by h.b.furuseth＠usit.uio.no 07 Jan '10

07 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD configured with CPPFLAGS=-DSLAP_NO_SL_MALLOC ./run test030-relay with slapd under valgrind Bad frees of op->o_req_ndn.bv_val and op->o_req_dn.bv_val: Invalid slap_sl_free() by 0x4864F1: do_extended (extended.c:187) Address 0xd8853a0 is 0 bytes inside a block of size 62 free'd by 0x487DAC: passwd_extop (passwd.c:321) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) Invalid slap_sl_free() by 0x486515: do_extended (extended.c:189) Address 0xd8855d0 is 0 bytes inside a block of size 62 free'd by 0x487DFF: passwd_extop (passwd.c:325) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) The four backtraces are surrounded by: at 0x4A05A31: free (vg_replace_malloc.c:325) by 0x4E707E5: ber_memfree_x (memory.c:152) by 0x4B7157: slap_sl_free (sl_malloc.c:481) <...backtrace above...> by 0x4444F8: connection_operation (connection.c:1109) by 0x444A7D: connection_read_thread (connection.c:1245) by 0x4C1AFE2: ldap_int_thread_pool_wrapper (tpool.c:685)

1 0

(ITS#6444) OpenLDAP 2.5 RoadMap Question
by j＠gropefruit.com 06 Jan '10

06 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny-AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.67.92.30) Please clarify this statement in your 2.5 roadmap: LDAPv3 extensions: *LDAP Transaction support Do you mean that SyncRepl will actually become legitimately enterprise-class, in that replication will work 100% of the time? Or does this mean transaction support for some other element unrelated to content synchronization? Why I ask: I've opened a few tickets on OpenLDAP in the past, related to replication issues involving multiple multimaster servers with a frontend employed (a hardware load balancer) to control writes. From time to time, it seems as though SyncRepl just "decides" to fail, and gives no indication ANYWHERE as to why. We log all sync activity, and we see no indication that the host is unreachable or down, and we see no performance delays when querying the DSAs manually. * All slapd servers' clocks are perfectly synchronized and are in a common time zone * Of all six multimasters, only two of them actually receive WRITES * All are 2.4.20 on amd64 kernel (Debian Lenny) * We see no discernible improvement when switching from refreshOnly to refreshAndPersist. Replication will work fine for awhile (in the most recent case, it worked for 16 days, having written test records ranging from 1000 to 50000 *repeatedly* without issues) and then just "fail" .... We have ruled out the following: * Bad hardware * slapd Configuration error (have posted our config before) * Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16 days) * Firewall policies between sites (wouldn't cause it to work and then not work). * slapd segfaulting or crashing in some way This behavior is quite lackluster for a business environment and is ultimately insufficient for any legitimate application. As far as I am concerned, the results are so unbelievably inconsistent that this is an affront to the way SyncRepl is represented/advertised. If it NEVER worked at all, at least THAT would be consistent. SyncRepl rarely makes any valid attempt to "sync up" when differences are detected between DSAs - SOMETIMES it feels like it, most of the time it does not. I hate to say it, but SyncRepl is a huge pile of misrepresentation and broken promises. So: Is transaction support intended to SOLVE these issues? If not, maybe you should invent something to replace SyncRepl altogether. J

1 0

Re: (ITS#6443) test022-ppolicy failure
by hyc＠symas.com 06 Jan '10

06 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.4.21 > OS: CentOS 5.4 > URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > During CentOS 5 x86_64 RPM build using the Buchan specfile: > >>>>>> Starting test022-ppolicy for bdb... > running defines.sh > Starting slapd on TCP/IP port 9065... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Testing account lockout... > Waiting 20 seconds for lockout to reset... > Testing password expiration > Waiting 20 seconds for password to expire... > Password expiration test failed >>>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) > > and then everything exited clean. testrun directory attached. > > This is not reproducible; a subsequent rebuild from the same specfile on the > same hardware finished clean. Given that these expiration tests are timing dependent, not sure there's anything real to track down here. -- -- 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

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