openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: ITS#7796 "not indexed" log messages
by ck＠cksoft.de 09 Mar '14

09 Mar '14

Hi, On Sun, 9 Mar 2014, michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting >> these in LDAP_DEBUG_FILTER. TRACE is already too verbose. > > I'm fine with any solution which avoids that these messages are sent to the > log in case of "loglevel stats stats2". I would also welcome a separate loglevel for these daemon messages: Mar 9 11:00:24 ldap1 slapd[19539]: daemon: read activity on 9 Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: activity on 1 descriptor Mar 9 11:00:24 ldap1 slapd[19539]: daemon: waked Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero They currently seem to be triggered by loglevel conns. So what about adding loglevel daemon or even conns2 for these. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

1 0

Re: ITS#7796 "not indexed" log messages
by michael＠stroeder.com 09 Mar '14

09 Mar '14

hyc(a)symas.com wrote: > I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting > these in LDAP_DEBUG_FILTER. TRACE is already too verbose. I'm fine with any solution which avoids that these messages are sent to the log in case of "loglevel stats stats2". Ciao, Michael.

1 0

ITS#7796 "not indexed" log messages
by hyc＠symas.com 09 Mar '14

09 Mar '14

I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting these in LDAP_DEBUG_FILTER. TRACE is already too verbose. -- -- 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#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by hyc＠symas.com 08 Mar '14

08 Mar '14

dror.harari(a)gmail.com wrote: > Full_Name: Dror Harari > Version: > OS: Windows 7 64bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.181.198.22) > > > The default compare functions start with: > > mdb_cmp_memn(const MDB_val *a, const MDB_val *b) > { > int diff; > ssize_t len_diff; > unsigned int len; > > len = a->mv_size; > len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size; > if (len_diff > 0) { > > This code assumes that ssize_t is signed and in all normal platforms it is. > However, on Windows Visal Studio 2010 (did not check others) it is defined as: > > #ifndef _SSIZE_T_DEFINED > #ifdef _WIN64 > typedef unsigned __int64 ssize_t; > #else > typedef _W64 unsigned int ssize_t; > #endif > #define _SSIZE_T_DEFINED > #endif > > So it is unsigned and len_diff would never become <0. If this is true, then you've found a bug in MSVC. The extra S in "SSIZE_T" means "signed." This is part of the C standard, and even the Microsoft documentation agrees with the standard (for once). http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%… You should file a bug report with Microsoft. Closing this ITS. > > There's a workaround to defined a custom compare function but one can rewrite > the default compare around this bug (that is, avoiding subtraction). > > This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where > the database had keys: > 00 00 00 01 65 > 00 00 00 02 65 > 00 00 00 03 65 > > Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65 > > -- -- 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#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by dror.harari＠gmail.com 08 Mar '14

08 Mar '14

Full_Name: Dror Harari Version: OS: Windows 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.181.198.22) The default compare functions start with: mdb_cmp_memn(const MDB_val *a, const MDB_val *b) { int diff; ssize_t len_diff; unsigned int len; len = a->mv_size; len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size; if (len_diff > 0) { This code assumes that ssize_t is signed and in all normal platforms it is. However, on Windows Visal Studio 2010 (did not check others) it is defined as: #ifndef _SSIZE_T_DEFINED #ifdef _WIN64 typedef unsigned __int64 ssize_t; #else typedef _W64 unsigned int ssize_t; #endif #define _SSIZE_T_DEFINED #endif So it is unsigned and len_diff would never become <0. There's a workaround to defined a custom compare function but one can rewrite the default compare around this bug (that is, avoiding subtraction). This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where the database had keys: 00 00 00 01 65 00 00 00 02 65 00 00 00 03 65 Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65

1 0

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

07 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 06 Mar '14

06 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 06 Mar '14

06 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 06 Mar '14

06 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

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