openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > Since 2.2.23, Debian has been carrying the following patch to the libldap_r > build process to explicitly link the library against the thread libraries. > (...) Is this the second half of the Debian patch you posted in ITS#4981 - so it'd be wrong to apply one one of these patches? -- Regards, Hallvard

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > (...) libtool does not pass -pthread through, -lpthread seems > to work though. > (...) > + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) > OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) > (...) This may be correct for Debian, but looks dubious as a general patch. On other systems that have a thread compiler switch it may be wrong to link the thread library "by hand" and omit the compiler switch, otherwise what's the compiler switch for? Their comments seem to indicate libtool is a better place to fix it. An OpenLDAP patch would likely need some 'if <debian>' code. (Note, I do not know Debian, nor specifics about differing Linux variants.) -- Regards, Hallvard

1 0

Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

kurt(a)OpenLDAP.org writes: > tls.c: In function `tls_thread_self': > tls.c:412: error: invalid operands to binary / > tls.c:415: warning: comparison between pointer and integer Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(), deliberately causes that for non-integer thread types. I wanted feedback from systems where that happens, since the OpenSSL doc says such systems are rare and this code can break there. The CRYPTO_set_id_callback manpage (from openssl/doc/crypto/threads.pod) says the function expects an integer thread ID, but that the function is not needed if getpid() returns different answers for different threads. And that this may be dangerous to relay on because one might compile a program on a machine where this is true and then run it on a machine where it is false. Anyway, possibly the correct fix is to not call this function on FreeBSD, it depends on getpid(). I have no idea. But since it presumably worked before: The simplest fix is to just remove the 'ok' and 'Check' code. But then we can again silently compile to bad code when the thread type is not an integer. Next simplest: simplify the 'ok' check to: enum { ok = sizeof(ldap_pvt_thread_t) <= sizeof(long) }; which will still let us know of systems where the conversion to ulong clearly loses data. Not quite a safe, since pointer<->integer conversions can do who-knows-what. But I guess OpenLDAP depends on those elsewhere. (Can sizeof(long) be < sizeof(pointer) on FreeBSD?) Also in any case cast tls_thread_self()'s return value to u.long. -- Regards, Hallvard

1 0

(ITS#4983) libldap_r/tls.c compile failure
by kurt＠OpenLDAP.org 23 May '07

23 May '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD RELENG_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.182.55.218) Submitted by: kurt /bin/sh ../..//libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c -fPIC -DPIC -o .libs/tls.o tls.c: In function `tls_thread_self': tls.c:412: error: invalid operands to binary / tls.c:415: warning: comparison between pointer and integer tls.c:415: error: enumerator value for `ok' not integer constant tls.c:416: error: negative width in bit-field `dummy' tls.c:416: error: size of array `Check' is negative tls.c:418: warning: return makes integer from pointer without a cast

1 0

(ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 23 May '07

23 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Since 2.2.23, Debian has been carrying the following patch to the libldap_r build process to explicitly link the library against the thread libraries. The comment at the time is: * libraries/libldap_r/Makefile.in: Code that uses pthreads *must* be linked with -pthread, even if it's a library; without this, the libldap_r library ends up with dangling unversioned reference to pthread_create() which gets resolved to a wrong version that causes segfaults on 64-bit platforms. Closes: #304549. See http://bugs.debian.org/304549 for the specific problems that this caused. --- openldap2.3-2.3.11~/libraries/libldap_r/Makefile.in 2005-12-01 13:48:50.000000000 +0100 +++ openldap2.3-2.3.11/libraries/libldap_r/Makefile.in 2005-12-02 10:05:17.637342000 +0100 @@ -56,7 +56,7 @@ XXLIBS = $(SECURITY_LIBS) $(LUTIL_LIBS) XXXLIBS = $(LTHREAD_LIBS) NT_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) -UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) +UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) $(LTHREAD_LIBS) .links : Makefile @for i in $(XXSRCS); do \

1 0

(ITS#4981) Try -lpthread before -pthread
by rra＠stanford.edu 23 May '07

23 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Debian has been carrying the included patch for a while, originally added against 2.1.22 with: + Fixed the undefined symbols in libldap_r.so.2 (closes: #195990). | configure.in: Try -lpthread before -pthread to link the thread library. libtool does not pass -pthread through, -lpthread seems to work though. and then refreshed some time later against 2.2.23 with: * configure.in: reinstate the remainder of the fix for 195990 from 2.1.22-2: give preference to -lpthread over -pthread in configure.in, because some archs (mipsel, at least) don't like -pthread. A quick search of other ITSes didn't reveal this particular report, but it did look like people building on AIX were manually setting library flags that may produce the same result. I'm sure that none of Debian's platforms will break with -lpthread instead of -pthread since we've been using this for a while, although I'm not sure if that's sufficient. I'd ideally like to see Debian stop carrying this patch around as a divergence, particularly since it means that the package has to re-run Autoconf during the build. Index: openldap2.3/configure.in =================================================================== --- openldap2.3.orig/configure.in 2007-05-23 15:05:12.000000000 -0700 +++ openldap2.3/configure.in 2007-05-23 15:09:38.000000000 -0700 @@ -1489,6 +1489,7 @@ case $ol_with_threads in auto | yes | po dnl OL_PTHREAD_TRY([-mt], [ol_cv_pthread_mt]) OL_PTHREAD_TRY([-kthread], [ol_cv_pthread_kthread]) + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) OL_PTHREAD_TRY([-pthreads], [ol_cv_pthread_pthreads]) OL_PTHREAD_TRY([-mthreads], [ol_cv_pthread_mthreads])

1 0

Re: (ITS#4980) misaligned memory access (openssl?)
by hyc＠symas.com 23 May '07

23 May '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.35 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost > always means a misaligned memory access. Not sure if this is OpenLDAP's problem > or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL > guys if necessary)... This stack trace is pretty exclusively OpenSSL and libc code. Unless there's been a heap corruption somewhere, it appears to be an OpenSSL issue. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu 23 May '07

23 May '07

Full_Name: Aaron Richton Version: 2.3.35 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost always means a misaligned memory access. Not sure if this is OpenLDAP's problem or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL guys if necessary)... current thread: t@11 [1] t_delete(0x11c303480, 0x0, 0xffffffff7f268340, 0x2000, 0x2190, 0x1004e4290), at 0xffffffff7d24fab8 [2] _malloc_unlocked(0x80, 0x0, 0x0, 0x11ad552e0, 0x11ad552e0, 0x0), at 0xffffffff7d24f068 [3] malloc(0x80, 0xffffffff7e502458, 0xffffffff7e5014f0, 0xf68, 0x24fd00, 0xc00), at 0xffffffff7d24ee94 =>[4] CRYPTO_malloc(num = ???, file = ???, line = ???) (optimized), at 0xffffffff7e2b2274 (line ~304) in "mem.c" [5] bn_expand_internal(b = ???, words = ???) (optimized), at 0xffffffff7e308140 (line ~336) in "bn_lib.c" [6] BN_bin2bn(s = ???, len = ???, ret = ???) (optimized), at 0xffffffff7e308940 (line ~451) in "bn_lib.c" [7] RSA_eay_private_decrypt(flen = ???, from = ???, to = ???, rsa = ???, padding = ???) (optimized), at 0xffffffff7e32f160 (line ~517) in "rsa_eay.c" [8] ssl3_get_client_key_exchange(s = ???) (optimized), at 0xffffffff7e625150 (line ~1732) in "s3_srvr.c" [9] ssl3_accept(s = ???) (optimized), at 0xffffffff7e6227d0 (line ~449) in "s3_srvr.c" [10] ldap_pvt_tls_accept(sb = 0x11be3ac90, ctx_arg = 0x1004e4290), line 866 in "tls.c" [11] connection_read(s = 189), line 1348 in "connection.c" [12] slapd_daemon_task(ptr = (nil)), line 2359 in "daemon.c"

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 23 May '07

23 May '07

Here is a simplified configuration that can be used to replicate the problem. I understand that such an error can not be easily triggered and in that sense might be considered as a low priority issue, but then again I believe it is worth mentioning. (I hope, I am not missing anything here...) # #include schemas here # access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * none argsfile /var/openldap/run/slapd.args pidfile /var/openldap/run/slapd.pid loglevel any modulepath /opt/OpenLdap/sbin moduleload back_bdb.la moduleload back_relay.la moduleload rwm.la backend bdb database bdb suffix "dc=foo,dc=bar" rootdn "uid=manager,dc=foo,dc=bar" rootpw "secret" directory /var/openldap/bdb access to * by * read database relay suffix "" relay "dc=foo,dc=bar" massage access to * by * read As you can see from the logs below, ops like this one: SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" SRCH attr=hasSubordinates objectClass fail, because slapd looks for an non-existent entry such as bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar"). The logs: ========= daemon: read activity on 11 connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 daemon: select: listen=7 active_threads=0 tvp=NULL do_search >>> dnPrettyNormal: <dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar> SRCH "dc=foo,dc=bar" 1 0 0 0 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: hasSubordinates objectClass conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" conn=0 op=5 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar" [rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar" >>> dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>, <dc=foo,dc=bar,dc=foo,dc=bar> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar") => bdb_dn2id("dc=bar,dc=foo,dc=bar") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=10 matched="dc=foo,dc=bar" text="" [rw] matchedDN: "dc=foo,dc=bar" -> "" >>> dnPretty: <> <<< dnPretty: <> send_ldap_response: msgid=6 tag=101 err=32 conn=0 op=5 SEARCH RESULT tag=101 err=32 nentries=0 text= Nikos Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: >> While slapd does not segfault anymore, slapd insists to concatenate >> unrelated database suffixes during search operations that look for attrs >> such as hasSubordinates. >> >> I mention this here because it seems to be related somehow > > As I could see it working as expected (by me, at least), I suggest you > cook a very simple example, consisting in two slapd.conf (one for the > remote server, and one for the offending mixed local-proxy-relay setup), > and as many data in LDIF format and submit it, so that you can show what > you consider an incorrect behavior. Otherwise, I don't see any further > indication of a bug. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > >

1 0

Re: (ITS#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

hyc(a)symas.com writes: > Try using ElectricFence, with my pthread patches. Still refuses to crash... -- Regards, Hallvard

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