openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7809) cross-compiling and openldap-thread-check.m4
by h.b.furuseth＠usit.uio.no 06 Mar '14

06 Mar '14

On Mon, 2014-03-03 at 02:09 +0000, stenn(a)ntp.org wrote: > openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH() > processing for the with_yielding_select stuff. This code has at least one typo > and at least one bug; it does not work in the case where one is > cross-compiling. OpenLDAP has no openldap-thread-check.m4. Maybe you're referring to some other package which checks how OpenLDAP uses threads. It could be doing something to match how OpenLDAP handles threads.

1 0

Re: (ITS#7815) mdb cannot retrieve inserted word
by hyc＠symas.com 05 Mar '14

05 Mar '14

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: gitorious mdb 2014-02-19 e2bdd44624a525 > OS: Fedora 20 64 bit > URL: http://www.strerror.com/mdb_bug_report/ > Submission from: (NULL) (192.94.73.31) > > > DUPLICATE bug report. New URL: for data file > http://www.strerror.com/mdb_bug_report/. > You can use the 3 non tgz files or download the tgz file which includes all of > them. Thanks for the report. This is now fixed in mdb.master. > I have a text file of words (words.txt). Each is 511 or less characters. When > inserting them into the database there comes a point when I can no longer > retrieve words that were successfully added with mdb_cursor_put. > > It should be put in the libraries/liblmdb directory. The Makefile has an added > command at the end. So put that, words.txt, and word_test.c in liblmdb directory > and run 'make words'. > > It will build and run a failing test. First it reads each line of words.txt. > Then it inserts them with their index as the value into mdb. If you change count > = 29523 on line 145 to be count = 29522 then it works. Inserting the next word > causes it to fail. > > It doesn't fail at the insert but it fails later. When iterating the cursor the > words are not in order and looking up individually not all words can be > retrieved. > > Also, changing line 151 to set val.mv_data, and val.mv_size to a string version > of i (the index, using sprintf), it works. > > This fails the same way on 64 bit Fedora and 64 bit Windows 7. > > -- -- 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#7813) lmdb multi threaded env creation on Win32 can fail
by hyc＠symas.com 05 Mar '14

05 Mar '14

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: gitorious mdb last commit Feb 19, 2014 e2bdd44624a525d4847c22d7ebf1ea4d154ed734 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.94.73.31) > > > There is a bug in lightning mdb in mdb.c when running Windows. When creating an > environment to the same file in multiple threads, an error can occur on the > OpenMutex call and some of the creations will fail. > > In mdb_env_setup_locks, mdb_env_excl_lock is called. > If it acquires an exclusive lock CreateMutex is called. > env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); > > If not OpenMutex is called. > env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); > > The OpenMutex call can fail if there is a thread context switch between the time > the exclusive lock is acquired and the time CreateMutex is called, because the > mutex to open has not actually been created yet. To be clear OpenMutex in > another thread gets run before CreateMutex in the first thread. > > The solution is to replace the OpenMutex calls with CreateMutex. It will either > open the mutex if it exists or create it if it does not. Setting the > bInitialOwner flag to FALSE as is already done is the recommended way to use > CreateMutex in this situation. There is already a note about multiple processes/threads opening the same environment at the same time. In short, don't do this. Even if the code is changed as you describe, if such a race condition can occur, then it also means that the check for mti_magic != MDB_MAGIC can also fail, so the fix is ineffective. -- -- 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

(ITS#7815) mdb cannot retrieve inserted word
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb 2014-02-19 e2bdd44624a525 OS: Fedora 20 64 bit URL: http://www.strerror.com/mdb_bug_report/ Submission from: (NULL) (192.94.73.31) DUPLICATE bug report. New URL: for data file http://www.strerror.com/mdb_bug_report/. You can use the 3 non tgz files or download the tgz file which includes all of them. I have a text file of words (words.txt). Each is 511 or less characters. When inserting them into the database there comes a point when I can no longer retrieve words that were successfully added with mdb_cursor_put. It should be put in the libraries/liblmdb directory. The Makefile has an added command at the end. So put that, words.txt, and word_test.c in liblmdb directory and run 'make words'. It will build and run a failing test. First it reads each line of words.txt. Then it inserts them with their index as the value into mdb. If you change count = 29523 on line 145 to be count = 29522 then it works. Inserting the next word causes it to fail. It doesn't fail at the insert but it fails later. When iterating the cursor the words are not in order and looking up individually not all words can be retrieved. Also, changing line 151 to set val.mv_data, and val.mv_size to a string version of i (the index, using sprintf), it works. This fails the same way on 64 bit Fedora and 64 bit Windows 7.

1 0

(ITS#7814) mdb cannot retrieve inserted word
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb 2014-02-19 e2bdd44624a525 OS: Fedora 20 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.94.73.31) I have a text file of words (words.txt). Each is 511 or less characters. When inserting them into the database there comes a point when I can no longer retrieve words that were successfully added with mdb_cursor_put. I will send the code to reproduce to your ftp server. It should be put in the libraries/liblmdb directory. The Makefile has an added command at the end. So put that, words.txt, and word_test.c in liblmdb directory and run 'make words'. It will build and run a failing test. First it reads each line of words.txt. Then it inserts them with their index as the value into mdb. If you change count = 29523 on line 145 to be count = 29522 then it works. Inserting the next word causes it to fail. It doesn't fail at the insert but it fails later. When iterating the cursor the words are not in order and looking up individually not all words can be retrieved. Also, changing line 151 to set val.mv_data, and val.mv_size to a string version of i (the index, using sprintf), it works. This fails the same way on 64 bit Fedora and 64 bit Windows 7.

1 0

(ITS#7813) lmdb multi threaded env creation on Win32 can fail
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb last commit Feb 19, 2014 e2bdd44624a525d4847c22d7ebf1ea4d154ed734 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.94.73.31) There is a bug in lightning mdb in mdb.c when running Windows. When creating an environment to the same file in multiple threads, an error can occur on the OpenMutex call and some of the creations will fail. In mdb_env_setup_locks, mdb_env_excl_lock is called. If it acquires an exclusive lock CreateMutex is called. env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); If not OpenMutex is called. env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); The OpenMutex call can fail if there is a thread context switch between the time the exclusive lock is acquired and the time CreateMutex is called, because the mutex to open has not actually been created yet. To be clear OpenMutex in another thread gets run before CreateMutex in the first thread. The solution is to replace the OpenMutex calls with CreateMutex. It will either open the mutex if it exists or create it if it does not. Setting the bInitialOwner flag to FALSE as is already done is the recommended way to use CreateMutex in this situation.

1 0

Re: (ITS#7812) Applictaion going down due to Ldap Break down and Restart is required
by quanah＠zimbra.com 05 Mar '14

05 Mar '14

--On March 5, 2014 at 9:17:52 AM +0000 m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 2.3.43-12.el5 > OS: Linux version 2.6.18-194.el5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > > > Dear All, > > we are getting application down almost like every 2/3 day > and Required LDAP Restart as a fix, can any one advice what could be the > problem .. > > Required to know, > what all data get cleared in ldap or refreshed during openLdap restart. > so that application will work fine. We have no idea who wrote your application or what it involves. You are running an unsupported release of OpenLDAP provided by RedHat. If you have issue with the OpenLDAP build provided by RedHat, then you must contact them for support. The openldap ITS system is not the correct place to be pursuing the issues you have with your RedHat build of an ancient unsupported version of OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7812) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accenture.com 05 Mar '14

05 Mar '14

Full_Name: Mohammed Noorishah Version: 2.3.43-12.el5 OS: Linux version 2.6.18-194.el5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.47.80) Dear All, we are getting application down almost like every 2/3 day and Required LDAP Restart as a fix, can any one advice what could be the problem .. Required to know, what all data get cleared in ldap or refreshed during openLdap restart. so that application will work fine.

1 0

RE: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accenture.com 04 Mar '14

04 Mar '14

Hi Howard, Sorry for the confusion - we have marked in property file as version = 3 Kindly advice on the same . Your help would be really grateful. Thanks and Regards Noorishah. 09663398005 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, March 04, 2014 9:49 PM To: Noorishah Burhan, M.; openldap-its(a)openldap.org Subject: Re: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 3.3 > OS: Unix > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > There is no OpenLDAP v3.3. It seems you're not using OpenLDAP software and you've contacted us in error. This ITS will be closed. > related to 7810, Wrongly given my email id ..corrected now > (m.noorishah.burhan(a)accenture.com) > > Kindly do the needful > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com

1 0

Re: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required
by hyc＠symas.com 04 Mar '14

04 Mar '14

m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 3.3 > OS: Unix > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > There is no OpenLDAP v3.3. It seems you're not using OpenLDAP software and you've contacted us in error. This ITS will be closed. > related to 7810, Wrongly given my email id ..corrected now > (m.noorishah.burhan(a)accenture.com) > > Kindly do the needful > > > -- -- 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