openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

Full_Name: Version: RE24 git a9b2c4fd2457fb502e9a2d47307e72ab2ec4b59d OS: openSUSE 11.4 x86_64 URL: Submission from: (NULL) (84.163.33.76) slapd was started with: -h "ldap://0.0.0.0:53123 ldapi://%2Ftmp%2Fopenldap-e2-infra-testbed" I can reproduce this always in a test bed but currently with a confidential customer configuration. Please request more information if really needed and I will try to provide a test config without confidential information. Core was generated by `/opt/openldap-RE24/libexec/slapd -d config,stats -h ldap://0.0.0.0:53123 ldapi:'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) info threads * 1 Thread 20121 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 (gdb) thread 1 [Switching to thread 1 (Thread 20121)]#0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) bt full #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 ludp = 0x100000000 next = 0x7fc67d751040 #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #2 0x00007fc67d515b1f in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #3 0x00007fff849df338 in ?? () No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. (gdb) frame 0 #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) info locals ludp = 0x100000000 next = 0x7fc67d751040

1 0

Re: (ITS#7140) mdb crash in slapadd(too large LDIF)
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 12:44:13 GMT, h.b.furuseth(a)usit.uio.no wrote: > The commit branches in mdb_tool_entry_<put,reindex> also reset > mdb->mi_attrs[*]->ai_cursor. Should the abort branches do the same? Also mdb_tool_entry_put() resets mdb_writes on commit but not abort. Relevant with slapadd -c, I suppose. mdb_tool_entry_reindex() never resets mdb_writes, so -q does not work. -- Hallvard

1 0

(ITS#7140) mdb crash in slapadd(too large LDIF)
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard When bumping into the database maxsize with slapadd: mdb_tool_entry_put() does not reset idcursor after mdb_txn_abort(), so idcursor gets closed twice and slapadd crashes. Blind fix: s/cursor = NULL;/idcursor = NULL;/ on tools.c line 684. This is what the mdb_txn_commit() branch does. The commit branches in mdb_tool_entry_<put,reindex> also reset mdb->mi_attrs[*]->ai_cursor. Should the abort branches do the same?

1 0

(ITS#7138) smbk5pwd: Fix uninitialized keys[1] in shadowLastChange
by fumiyas＠osstech.co.jp 27 Jan '12

27 Jan '12

Full_Name: SATOH Fumiyasu Version: 2.4.28 OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.28-smbk5pwd-fix-shadow-support… Submission from: (NULL) (220.100.28.128) slapd dies with the following message if "smbk5pwd-enable shadow" is set in slapd: mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed.

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by quanah＠zimbra.com 27 Jan '12

27 Jan '12

--On Friday, January 27, 2012 12:46 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> -R/opt/zimbra/openssl/lib > > FWIW: > Setting rpath with -R did not work for me on Linux. I had to use > -Wl,-rpath instead. I did not re-test recently though. It only works on older linux systems, some of which I still support. For me, newer ones ignore it and do the rest of the linking correctly. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by holm＠informatik.umu.se 27 Jan '12

27 Jan '12

--On 26 januari 2012 13.30.22 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > There is something wrong in what you're doing, I don't know where. I built using a > builddir (since I don't usually, but you did), and it worked correctly for me. I have found the problem! If you use --disable-static without using --enable-dynamic, the executables are dynamically linked BUT with the wrong rpath. In this case, I think configure should either quit with an error pointing out the contradiction OR link dynamically with the correct rpath. Thank You for your help in sorting this out! Regards, Åke Holmlund

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by michael＠stroeder.com 27 Jan '12

27 Jan '12

quanah(a)zimbra.com wrote: > -R/opt/zimbra/openssl/lib FWIW: Setting rpath with -R did not work for me on Linux. I had to use -Wl,-rpath instead. I did not re-test recently though. Ciao, Michael.

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by quanah＠zimbra.com 26 Jan '12

26 Jan '12

--On Thursday, January 26, 2012 9:11 AM +0000 holm(a)informatik.umu.se wrote: > --On 25 januari 2012 13.47.34 -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > I handle OpenLDAP the same way as all other software. This is basically > what I do: > > cd OpenLDAPsources > mkdir builddir > cd builddir > env CFLAGS="-O2" \ > ../configure \ > --prefix=/opt/OpenLDAP \ > --enable-shared \ > --disable-static \ > --sysconfdir=/var/conf \ > --localstatedir=/var/conf/openldap/var \ > --disable-hdb \ > --disable-monitor \ > --enable-rlookups \ > --enable-accesslog \ > --enable-modules > make > make install > > Everything is installed in the right place but the rpath is wrong. > One interesting thing. The executables are not created in the .libs > direcotrys and they are not relinked at install. The .libs directorys > are created but not used. The libraries, on the other hand, ARE > created in the .libs directorys and relinked at install time. There is something wrong in what you're doing, I don't know where. I built using a builddir (since I don't usually, but you did), and it worked correctly for me. Note that my dependancy libs are all also in their own dirs, so I have to specify how to link to them in configure/make, but I do not tell it where to link to for finding the OpenLDAP libs: LD_LIBRARY_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyru s-sasl/lib:/opt/zimbra/libtool/lib LDFLAGS="-L/opt/zimbra/openssl/lib -L/opt/zimbra/bdb/lib -L/opt/zimbra/cyrus-sasl/lib -L/opt/zimbra/libtool/lib -R/opt/zimbra/openssl/lib -R/opt/zimbra/bdb/lib -R/opt/zimbra/libtool/lib -R/opt/zimbra/cyrus-sasl/lib" CPPFLAGS="-I/opt/zimbra/bdb/include -I/opt/zimbra/cyrus-sasl/include -I/opt/zimbra/openssl/include -I/opt/zimbra/libtool/include" CFLAGS="-g -O0" ../configure --prefix=/opt/zimbra/openldap-2.4.28-linktest --with-cyrus-sasl --with-tls=openssl --enable-dynamic --enable-slapd --enable-modules --enable-backends=mod --disable-shell --disable-sql --disable-bdb --disable-ndb --enable-overlays=mod --enable-debug --enable-spasswd --enable-crypt LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make depend LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make -j2 LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make prefix=/opt/zimbra/openldap-2.4.28-linktest install strip="" [build@zre-rhel6-64 builddir]$ cd /opt/zimbra/openldap-2.4.28-linktest/bin/ [build@zre-rhel6-64 bin]$ ldd ldapsearch linux-vdso.so.1 => (0x00007fffa99ff000) libldap-2.4.so.2 => /opt/zimbra/openldap-2.4.28-linktest/lib/libldap-2.4.so.2 (0x00007f780f6cd000) liblber-2.4.so.2 => /opt/zimbra/openldap-2.4.28-linktest/lib/liblber-2.4.so.2 (0x00007f780f4bc000) libsasl2.so.2 => /opt/zimbra/cyrus-sasl-2.1.25.4z/lib/libsasl2.so.2 (0x00007f780f2a1000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003000e00000) libssl.so.1.0.0 => /opt/zimbra/openssl/lib/libssl.so.1.0.0 (0x00007f780f03b000) libcrypto.so.1.0.0 => /opt/zimbra/openssl/lib/libcrypto.so.1.0.0 (0x00007f780ec8b000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003003e00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003003200000) libc.so.6 => /lib64/libc.so.6 (0x0000003001200000) /lib64/ld-linux-x86-64.so.2 (0x0000003000a00000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003004200000) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by holm＠informatik.umu.se 26 Jan '12

26 Jan '12

--On 25 januari 2012 13.47.34 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, January 25, 2012 9:33 PM +0000 holm(a)informatik.umu.se wrote: > >> Full_Name: ?ke Holmlund >> Version: 2.4.28 >> OS: Solaris 10, Ubuntu 10.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:6b0:e:4a43::25) >> >> >> After compiling and installing OpenLDAP, the tools and servers are linked >> with the wrong library path. They use the libraries in the source tree >> instead of the installed libraries. > > It sounds to me like you failed to correctly set your paths etc while compiling and > installing then. I build OpenLDAP on some 20 different Linux distributions with a > large variety of gcc and kernel releases, and the RPATH always correct. I handle OpenLDAP the same way as all other software. This is basically what I do: cd OpenLDAPsources mkdir builddir cd builddir env CFLAGS="-O2" \ ../configure \ --prefix=/opt/OpenLDAP \ --enable-shared \ --disable-static \ --sysconfdir=/var/conf \ --localstatedir=/var/conf/openldap/var \ --disable-hdb \ --disable-monitor \ --enable-rlookups \ --enable-accesslog \ --enable-modules make make install Everything is installed in the right place but the rpath is wrong. One interesting thing. The executables are not created in the .libs direcotrys and they are not relinked at install. The .libs directorys are created but not used. The libraries, on the other hand, ARE created in the .libs directorys and relinked at install time. Regards, Åke Holmlund -------------------------------------------------------------------------- Åke Holmlund Phone: 090 - 786 57 16 Umeå University Fax: 090 - 786 65 50 Dept of Informatics Email: holm(a)informatik.umu.se 901 87 Umeå SWEDEN > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#7128 OpenLDAP for Win7 error
by hyc＠symas.com 25 Jan '12

25 Jan '12

The OpenLDAP Project has nothing to do with the file you referenced. Contact whoever created those binaries for assistance. This ITS will be closed. -- -- 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