openldap-bugs June 2019

openldap-bugs@openldap.org

27 participants
104 discussions

Re: (ITS#8970) bind fails when length value is multi-byte
by ondra＠mistotebe.net 17 Jun '19

17 Jun '19

Hi Leo, in my tests, everything is handled correctly. Have you been able to reproduce this with an up-to-date version of OpenLDAP? If so, can you provide slapd output (stderr) with -d -1? This is different from slapd syslog output in that libldap/liblber logging is also included. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8695) _sleep is deprecated
by hyc＠symas.com 17 Jun '19

17 Jun '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Windows 10 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > When building OpenLDAP, we find: > > C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c: In function > 'do_read': > C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:384:11: > warning: '_sleep' is deprecated [-Wdeprecated-declarations] > sleep( delay ); > ^~~~~ > In file included from > C:/msys64/home/build/sold-master/openldap/include/ac/stdlib.h:26:0, > from > C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:24: > C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:613:24: note: declared > here > _CRTIMP void __cdecl _sleep(unsigned long _Duration) > __MINGW_ATTRIB_DEPRECATED; > ^~~~~~ > > This comes from: > > include/ac/unistd.h > > The correct function call is Sleep > > #ifdef _WIN32 > #define sleep Sleep > #endif > > should resolve it. > > Need to be careful here. M$ says the function is supported as of Windows XP https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-s… but is not defined in any header files until Windows Vista. Any "fix" should only use Sleep if the current M$ SDK is new enough; the rest of the code still builds on Windows XP. -- -- 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#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com 17 Jun '19

17 Jun '19

On ma, 17 kesä 2019, Ondřej Kuzník wrote: >On Fri, Jun 14, 2019 at 11:50:20AM +0000, abokovoy(a)redhat.com wrote: >> On pe, 14 kesä 2019, Ondřej Kuzník wrote: >>> Hi Alexander, >>> as of commit 6a5e30674b63b17587738ba9a3d1ea3633c33fb1, OpenLDAP master >>> now ships and installs a new header <openldap.h> that should expose >>> ldap_init_fd(). Could you check this will work for Samba before we apply >>> this change in 2.4? >> Thanks. I've compiled openldap git master and installed it, I can see >> $prefix/include/openldap.h with ldap_init_fd() and man pages have proper >> references to openldap.h. >> >> Looks good to me. Once 2.4 becomes available, we can add support of this >> to Samba. > >Hi Alexander, >this has been integrated into RE24 and should be available with the >2.4.48 release onwards. Great, thank you, Ondřej. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by ondra＠mistotebe.net 17 Jun '19

17 Jun '19

On Fri, Jun 14, 2019 at 11:50:20AM +0000, abokovoy(a)redhat.com wrote: > On pe, 14 kesä 2019, Ondřej Kuzník wrote: >> Hi Alexander, >> as of commit 6a5e30674b63b17587738ba9a3d1ea3633c33fb1, OpenLDAP master >> now ships and installs a new header <openldap.h> that should expose >> ldap_init_fd(). Could you check this will work for Samba before we apply >> this change in 2.4? > Thanks. I've compiled openldap git master and installed it, I can see > $prefix/include/openldap.h with ldap_init_fd() and man pages have proper > references to openldap.h. > > Looks good to me. Once 2.4 becomes available, we can add support of this > to Samba. Hi Alexander, this has been integrated into RE24 and should be available with the 2.4.48 release onwards. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9037) observing crash in mdb_cursor_put()
by grobins＠pulsesecure.net 16 Jun '19

16 Jun '19

Full_Name: Robins George Version: 0.9.18 OS: Centos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.244.154.134) I am seeing LMDB crash, please find the stack trace. #0 0x009e362e in mdb_cursor_put (mc=0xffd59bb8, key=0xffd59d14, data=0xffd59d0c, flags=0) at mdb.c:6688 #1 0x009e48ec in mdb_put (txn=0xd74d3008, dbi=2, key=0xffd59d14, data=0xffd59d0c, flags=0) at mdb.c:8771 #2 0x00f5cef8 in LMDB::LMDBContext::createSession (this=0x80cc610, sid=0x80cd0fc "sid1422419e5fd6cd224f278d74293c50f5ef96593700000000+") at lmdbint.cc:460 #3 0x0805398e in updateLMDB (request=..., forward=@0xffd59fff) at sessionserver.cc:1154 #4 processRequestWithoutResponse (request=..., forward=@0xffd59fff) at sessionserver.cc:1240 #5 0x08056936 in ZSubHandler::ioReady (this=0xffd5aa1c, fd=20) at sessionserver.cc:1501 #6 0x00f870d2 in runCoreDispatcher (default_t=<value optimized out>, flags=-1) at fds.cc:889 #7 0x00f87b37 in DSEvntFds::runDispatcher () at fds.cc:945 #8 0x08056248 in main () at sessionserver.cc:1820 Anybody has seen similar issue before?

1 0

Re: (ITS#7996) Tighten race in ldap_int_initialize
by quanah＠symas.com 16 Jun '19

16 Jun '19

--On Sunday, June 16, 2019 7:54 PM +0000 quanah(a)symas.com wrote: > --On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 > <Armin.Tueting(a)tueting-online.com> wrote: > >> Hello Quanah, >> >> I'm following OPENLDAP_REL_ENG_2_4. The commit >> 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It >> won't start at all... >> >> I'm using a fairly up-to-date CentOS 7 version... >> 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 > > Hi, > > Thanks for the report. When reporting issues, please keep them on the=20 > OpenLDAP bug tracking list, rather than directly emailing individuals. > > I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 > pass via make test, and I can start slapd just fine w/o debug mode). > I'll=20 test on centos7 and see if I can reproduce. I'm also unable to reproduce any issues with current RE24 (0c44b22d3e347f2f05f913e7e3ffa907816574ed) under fully updated Centos7: CentOS Linux release 7.6.1810 (Core) kernel-headers.x86_64 3.10.0-957.21.2.el7 @updates You will need to provide substantially more information about what you're seeing. I would start with starting slapd in full debug mode (add -d -1 to the startup flags to slapd) and see what issue(s) it reports. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7996) Tighten race in ldap_int_initialize
by quanah＠symas.com 16 Jun '19

16 Jun '19

--On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 <Armin.Tueting(a)tueting-online.com> wrote: > Hello Quanah, > > I'm following OPENLDAP_REL_ENG_2_4. The commit > 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It > won't start at all... > > I'm using a fairly up-to-date CentOS 7 version... > 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 Hi, Thanks for the report. When reporting issues, please keep them on the=20 OpenLDAP bug tracking list, rather than directly emailing individuals. I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 pass via make test, and I can start slapd just fine w/o debug mode). I'll=20 test on centos7 and see if I can reproduce. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9035) LDMB: 0.9.23: mdb_env_set_maxreaders() not honoured?
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <c68dedc0-e022-509b-da5a-e9300d71e39e(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below | |The maxreaders setting doesn't persist after all processes have closed \ |the environment. |Therefore it returns to its default value when the next process opens \ |the environment. | |The code works as designed. There is no bug here. Closing this ITS. Ok. But please let me wonder why it is part of a DB dump, then, if it has nothing to do with the persistent state of a DB, but rather with the coding environment that is recreated each time from scratch. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Re: (ITS#9036) LDMB: 0.9.23: mdb_env_info() does not report latest mapsize() after transaction abort
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <b0311a63-3757-5b69-676a-bd8293e34c1e(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below |> |> |Your README states that the behavior in LMDB 0.9.23 is different than \ |in 0.9.22 but that |is incorrect. No changes to set_mapsize() behavior were made between \ |0.9.22 and 0.9.23. Yeah!! Mind you, i have even looked into the git history once AlpineLinux switched to 0.9.23 and i came to the very same conclusion! But one thing is plain: on AlpineLinux, with musl libc, from July 2018 to January 2019, i ran bogofilter with LMDB 0.9.22 exactly as it is still in bogofilter upstream and on the one branch in the ball i provided under the URL above. Doing monthly dump + rebuild of my spam database to vacuumize the thing. Without any problems. Then after my weekly system upgrade, which (also?) came with LMDB 0.9.23 i suddenly saw crashes, on a Saturday night! You can read the two mails [1,2] if you wanna. [1] https://www.bogofilter.org/pipermail/bogofilter-dev/2019q1/003515.html [2] https://www.bogofilter.org/pipermail/bogofilter-dev/2019q1/003516.html |Closing this ITS. Well ok, if it is so designed that set_mapsize() is not meant to survive a transaction abort, then it may be so. But then it should possibly be documented that after a transaction abort all environmental settings need to be reestablished, as they vanish after an abortion. I.e., that they only become persistent after a successful commit. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Re: (ITS#9034) LDMB: 0.9.22/3: initial mdb_env_set_mapsize() is problematic
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <1c3b8393-3524-311e-0287-d87ef7e2de37(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below. | |The code works as designed. No changes to mapsize handling were made \ |between 0.9.22 and 0.9.23. |Closing this ITS. It did not work with 0.9.22 already. Sorry for the messy README, if you have not read it in its entirety, the long story possibly was too long. But if an initial set_mapsize() causes crashes further on, then this is a design i do not understand. I mean, i have found workarounds (leaving off code) which work stable since one year in two weeks from now, on musl as well as GNU C libraries, and Matthias Andree tested on FreeBSD and Solaris, if i recall correctly, and so it is ok for me. That is all i know. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2019