openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#8015) memcpy() overlapping in many places
by leo＠yuriev.ru 23 Jan '15

23 Jan '15

> * > Date: Sat, 03 Jan 2015 22:48:15 +0000 > From: Howard Chu <hyc(a)symas.com> > To: kurt(a)OpenLDAP.org, openldap-its(a)OpenLDAP.org > Subject: Re: (ITS#8015) memcpy() overlapping in many places > * > kurt(a)OpenLDAP.org wrote: > > AC_MEMCPY is generally memove(3). It would only be memcpy(3) if both = > > memmove(3) or bcopy(3) were not available. So at most your patch will = > > cause link errors. > > Closing this ITS. The patch is obviously invalid. I decided after all to answer regarding AC_MEMCPY as this illustrative case mess of the source code (aka rebus code style). In my opinion it also illustrates the substitution of concepts in conversations about the quality of code and demonstrates the incorrect use of tools such as autconf. If we look at the source code, you will see that there are three things that are relevant to the discussion:directly memmove(), directly memcpy() and macro AC_MEMCPY. Simultaneous use directly memcpy() and AC_MEMCPY seems like a legacy effort for compatibility. Ok, this is not a problem, just a less of changes. But in fact AC_MEMCPY used for overlapped source and destination, like a memmove(). Ok, as you noted, the AC_MEMCPY macro will be expanded to memmove(), therefore it is no problems with overlapped source and destination. But then, why macro is really named as 'MEMCPY'? However AC_MEMCPY will be _silently_ expanded to memcpy() if no memmove() or bcopy() is available! What we have at the end? - Completely unnecessary macro which is confusing because of the inappropriate name. - The possibility of incorrect and quiet substitution macro that will lead to a wonderful unexpected errors. - Misuse autoconf, which leads to the creation of compatibility issues, rather than overcome them. This sort of thing I call "rebus code style" ;) Leonid.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru 23 Jan '15

23 Jan '15

> * > Date: Thu, 22 Jan 2015 07:49:15 +0100 > From: Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> > To: leo(a)yuriev.ru, openldap-its(a)OpenLDAP.org > Subject: Re: (ITS#8018) a lot of warnings building with -Wall > * > On 22/01/15 06:13, leo(a)yuriev.ru wrote: > > I unexpectedly detected that the variadic macro feature of C99 was > > already used in OpenLDAP 2.4 ;) > > Look a bit closer: > > > grep -R __VA_ARGS__ * > > build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, > > __VA_ARGS__) > > contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, > > format, __VA_ARGS__) > > ltmain.sh is a shell/code library generated by GNU libtool. > Lots of stuff in there which we do not use. > > > libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", > > mdb_func_, __LINE__, __VA_ARGS__) > > servers/slapd/back-bdb/back-bdb.h:#define > > BDB_LOG_PRINTF(env,txn,fmt,...) > > (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) > > servers/slapd/back-bdb/back-bdb.h:#define > > BDB_LOG_PRINTF(env,txn,fmt,...) > > __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__) > > Debug macros which are off by default and fall back to ((void)0) > or somesuch. Hallvard, thanks. Of course, I understand that __VA_ARGS__ are used only for debugging currently. But this is makes me think that recent development and testing of OpenLDAP are carried out only in today's environment (modern Linux and gcc). Could anyone say about the list of a system-compiler pairs with which OpenLDAP was tested or just successfully compiled? For instance, in our fork we plan limit the support to modern systems with gcc, clang and last msvc compilers. However, users ask us - What platforms are not supported by your fork in comparison with original OpenLDAP? For example https://gcc.gnu.org/gcc-4.1/buildstat.html Is there something similar for OpenLDAP? Leonid.

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by h.b.furuseth＠usit.uio.no 23 Jan '15

23 Jan '15

On 23/01/15 18:10, hyc(a)symas.com wrote: >> LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled >> version of LMDB should be used with a given version of OpenLDAP. > > I've already had this conversation with the gentoo maintainers; they > refuse to listen to reason. It's all their problem now. Still, memalign() is a problem. mdb.c defines HAVE_MEMALIGN, but it may be wrong for the user to -D"HAVE_MEMALIGN" since that may omit whatever #include file declares it. <malloc/malloc.h> (some Apple stuff I think), <malloc.h> dunno what else. We could drop memalign. malloc(desired space + 1 OS page), then adjust for alignment. On machines with a sane linear address space where we can tell alignment from the address, anyway. On weirder hosts, you care about them, omit alignment altogether if posix_memalign is missing. And omit O_DIRECT/F_NOCACHE in mdb_env_copy2(). I gather those are why we need alignment. Branch "mdb/memalign" in <git://git.uio.no/u/hbf/openldap.git> has draft code. Daniel: You can try that branch, and configure with CPPFLAGS="-DMDB_MEMALIGN_METHOD=2". I guess the preprocessor test should be "defined(a test for Darwin: __APPLE__, _MACOSX_ or..?)" and not __PPC__. PowerPC is an architecture, while features like posix_memalign are defined by compilers/operating systems. The macports issue disables mdb for Darwin. Or maybe not, I don't know Mac, Darwin, PPC or Gentoo, or if you just said this has been resolved, so I'll stay out of of that issue. -- Hallvard

1 0

Re: (ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by hyc＠symas.com 23 Jan '15

23 Jan '15

quanah(a)zimbra.com wrote: > Just a note: > > LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled > version of LMDB should be used with a given version of OpenLDAP. I've already had this conversation with the gentoo maintainers; they refuse to listen to reason. It's all their problem now. -- -- 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#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by quanah＠zimbra.com 23 Jan '15

23 Jan '15

--On Friday, January 23, 2015 1:18 PM +0000 daniel.ibnzayd(a)inquisitor.com wrote: > Full_Name: Daniel Ibn Zayd > Version: openldap-2.4.40-r3 > OS: PPC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.84.1.2) > > > This is a followup to a previous ticket. Based on what I learned from > that, I went ahead and tried to install the latest openldap on Gentoo > Prefix. It pulls in lmdb-0.9.14 which I understand now to be the > preferred database backend over db, for example. I successfully fixed one > PPC error, replacing -soname with -install_name (ld throws an error > here), but I am left with an error having to do with _posix-memalign: Just a note: LMDB should not be pulled separately from OpenLDAP. I.e., only the bundled version of LMDB should be used with a given version of OpenLDAP. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8034) lmdb-0.9.14 | Undefined symbols for architecture ppc: "_posix_memalign" referenced from _mdb_env_copyfd2 | ld: symbol(s) not found for architecture ppc
by daniel.ibnzayd＠inquisitor.com 23 Jan '15

23 Jan '15

Full_Name: Daniel Ibn Zayd Version: openldap-2.4.40-r3 OS: PPC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (166.84.1.2) This is a followup to a previous ticket. Based on what I learned from that, I went ahead and tried to install the latest openldap on Gentoo Prefix. It pulls in lmdb-0.9.14 which I understand now to be the preferred database backend over db, for example. I successfully fixed one PPC error, replacing -soname with -install_name (ld throws an error here), but I am left with an error having to do with _posix-memalign: Undefined symbols for architecture ppc: "_posix_memalign", referenced from: _mdb_env_copyfd2 in mdb.o ld: symbol(s) not found for architecture ppc collect2: ld returned 1 exit status Over at MacPorts, they are recommending disabling mdb, but this doesn't seem to be a real fix: http://trac.macports.org/changeset/130560 The better fix I think would be to test for _posix_memalign, and fall back to valloc on older Macs. In terms of C preprocessor macros, I believe "powerpc" and "PPC" to be drerecated definitions; "__ppc__" and "__PPC__" being valid. (Reference: http://nadeausoftware.com/articles/2012/02/c_c_tip_how_detect_processor_typ… ) Thank you in advance for your time.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by hyc＠symas.com 22 Jan '15

22 Jan '15

quanah(a)zimbra.com wrote: > --On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price > <freebsd(a)jonathanprice.org> wrote: > >> I do apologise for the confusion, I'll try to clarify below: >> >> Here is the command you ran successfully: >> /opt/zimbra/openldap/sbin/slappasswd -h >> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >> module-load=pw-sha2 -s test >> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >> >> Here is an example of me running just a plain SHA512 >> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 >> {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUN >> zLDBMxfqa2Ob1f1ACio/w== >> >> And here is an example of me running a salted SHA512 (SSHA512) >> slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 -s test >> Password verification failed. >> >> I hope this helps to clarify. > > Yes, thank you. So I'm using 2.4.39. There were some minor changes to > slapd-sha2 in 2.4.40. I will see if I can reproduce the issue with current > RE24. I have a FreeBSD 9 VM here with 2.4.40 installed from ports. Both SHA512 and SSHA512 work fine on it. Doesn't look to me like there's any OpenLDAP bug here, this is one for the FreeBSD folks to sort out. -- -- 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#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 22 Jan '15

22 Jan '15

Sorry for the slow response, but I have made some progress with the issue= .=0A=0A(as an aside, I installed a build from LTB, and unfortunately it d= oes not=0Acontain this overlay)=0A=0AI have detailed my findings (includi= ng some trawling through the source) =0Aover on the FreeBSD bug tracker, = as I suspect it could well be a platform=0Arelated issue. Nonetheless, it= might be worth reading:=0Ahttps://bugs.freebsd.org/bugzilla/show_bug.cgi= ?id=3D197004=0A=0AJanuary 14 2015 4:31 PM, "Quanah Gibson-Mount" <quanah@= zimbra.com> wrote: =0A> --On Wednesday, January 14, 2015 11:00 AM +0000 f= reebsd(a)jonathanprice.org=0A> wrote:=0A> =0A>> Hi,=0A>> =0A>> I tried 2.4.= 39 under FreeBSD and still had the same issue.=0A>> =0A>> I have also tri= ed the packages for both CentOS 7 and Debian Wheezy, but=0A>> unfortunate= ly neither of them include the SHA2 overlay by default.=0A>> =0A>> Finall= y, I tried installing zimbra-core and zimbra-ldap under CentOS.=0A>> When= I used this installation, it worked successfully.=0A>> =0A>> I ran slapd= -V on the zimbra installation, and it's 2.4.39. However,=0A>> based on i= t still not working on 2.4.39 on FreeBSD it appears to have=0A>> narrowed= it down to two reasons: - An issue with the packaging under=0A>> FreeBSD= =0A>> - The functionality is specific to Zimbra=0A>> =0A>> The next step = in the process to narrow this down is to do a manual=0A>> compilation on = CentOS, including the SHA2 overlay. If this works, then it=0A>> would con= firm it to be a FreeBSD issue, and if it doesn't work that would=0A>> str= ongly suggest that Zimbra has modified something.=0A> =0A> You could simp= ly grab the LTB project builds. I'm pretty sure they build=0A> out the co= ntrib modules.=0A> =0A> In any case, I already noted that Zimbra doesn't = patch anything in OpenLDAP=0A> that would affect this area.=0A> =0A> --Qu= anah=0A> =0A> --=0A> =0A> Quanah Gibson-Mount=0A> Platform Architect=0A> = Zimbra, Inc. =0A> _______________________________=0A> =0A> Zimbra :: the = leader in open source messaging and collaboration

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 21 Jan '15

21 Jan '15

On 22/01/15 06:13, leo(a)yuriev.ru wrote: > I unexpectedly detected that the variadic macro feature of C99 was > already used in OpenLDAP 2.4 ;) Look a bit closer: > grep -R __VA_ARGS__ * > build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, > __VA_ARGS__) > contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, > format, __VA_ARGS__) ltmain.sh is a shell/code library generated by GNU libtool. Lots of stuff in there which we do not use. > libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", > mdb_func_, __LINE__, __VA_ARGS__) > servers/slapd/back-bdb/back-bdb.h:#define > BDB_LOG_PRINTF(env,txn,fmt,...) > (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) > servers/slapd/back-bdb/back-bdb.h:#define > BDB_LOG_PRINTF(env,txn,fmt,...) > __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__) Debug macros which are off by default and fall back to ((void)0) or somesuch.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by leo＠yuriev.ru 21 Jan '15

21 Jan '15

I unexpectedly detected that the variadic macro feature of C99 was already used in OpenLDAP 2.4 ;) grep -R __VA_ARGS__ * build/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__) contrib/ldapc++/ltmain.sh:# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__) libraries/liblmdb/mdb.c: fprintf(stderr, "%s:%d " fmt "\n", mdb_func_, __LINE__, __VA_ARGS__) servers/slapd/back-bdb/back-bdb.h:#define BDB_LOG_PRINTF(env,txn,fmt,...) (env)->log_printf((env),(txn),(fmt),__VA_ARGS__) servers/slapd/back-bdb/back-bdb.h:#define BDB_LOG_PRINTF(env,txn,fmt,...) __db_logmsg((env),(txn),"DIAGNOSTIC",0,(fmt),__VA_ARGS__)

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