openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 16:52:05 GMT, michael(a)stroeder.com wrote: > Hmm, it seems I get better result linking smbk5pwd with > contrib/slapd-modules/smbk5pwd/Makefile containing: > > LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs > -L../../../libraries/liblber/.libs > > instead of just > > LDAP_LIB=-lldap_r -llber > > Is that the right solution when rpath is already set when invoking > configure? If you build *and install* the rest of OpenLDAP first and then build smbk5pwd, I imagine it'll work fine if -L and -rpath are the same. Otherwise you should point -L at where all the libraries-to-be-installed are, which with a dynamic build is the .lib/ directories. After all -L is for build time and -rpath for runtime, and they should be set so that you build against the same libraries you will run with. At least I hope that's all. I wouldn't be surprised if some libtool magic introduces more complications:-( -- Hallvard

1 0

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

28 Jan '12

michael(a)stroeder.com wrote: > Uumpf! I forgot to update my local version of > > contrib/slapd-modules/smbk5pwd/Makefile > > after pulling from git. This Makefile does not use prefix and LDFLAGS used > with ./configure before. Hmm, it seems I get better result linking smbk5pwd with contrib/slapd-modules/smbk5pwd/Makefile containing: LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs -L../../../libraries/liblber/.libs instead of just LDAP_LIB=-lldap_r -llber Is that the right solution when rpath is already set when invoking configure? Ciao, Michael.

1 0

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

28 Jan '12

Hallvard B Furuseth wrote: > On Sat, 28 Jan 2012 15:10:24 GMT, michael(a)stroeder.com wrote: >> Core was generated by `/opt/openldap-RE24/libexec/slapd (...) >> (...) >> #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 > > Looks like slapd is linked to the wrong libldap_r, and you need > to configure with something like > > $ pr=/opt/openldap-RE24 > $ ./configure --prefix=$pr LDFLAGS="-L$pr/lib -Wl,-rpath,$pr/lib" Uumpf! I forgot to update my local version of contrib/slapd-modules/smbk5pwd/Makefile after pulling from git. This Makefile does not use prefix and LDFLAGS used with ./configure before. Please close this ITS. Ciao, Michael.

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 15:10:24 GMT, michael(a)stroeder.com wrote: > Core was generated by `/opt/openldap-RE24/libexec/slapd (...) > (...) > #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 Looks like slapd is linked to the wrong libldap_r, and you need to configure with something like $ pr=/opt/openldap-RE24 $ ./configure --prefix=$pr LDFLAGS="-L$pr/lib -Wl,-rpath,$pr/lib" -- Hallvard

1 0

(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

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