- openldap-bugs - openldap.org

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 15 Mar '14

15 Mar '14

> Did you already try with this? > > rwm-drop-unrequested-attrs no If you look through the messages (http://www.openldap.org/its/index.cgi?findid=7673), you will see that the same suggestion was made by Pierangelo Masarati 6 months ago in followup 5. My response in followup 6 was that it doesn't work. A quick test indicates that it still does not work in 2.4.39. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 15 Mar '14

15 Mar '14

This is a cryptographically signed message in MIME format. --------------ms000109040804090309020609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Russell.Mosemann(a)cune.edu wrote: > simply referencing rwm >=20 > overlay rwm >=20 > returns no search results at all, if an attribute is specified for the > search. Specifying no attributes returns all of the allowed attributes.= > Commenting the line above permits the specified attribute to be returne= d, > as expected. Did you already try with this? rwm-drop-unrequested-attrs no Ciao, Michael. --------------ms000109040804090309020609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MDkxMjE4WjAj BgkqhkiG9w0BCQQxFgQUrABzEjElf3V/cUntQuLyr7sa6GcwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAv0di+TXxwjmc85Xw+S9qBwQag6dOQupE IkAwHTdBFaFAYayl0ohH4+WQk2G7lxxyy1Mr1dmva4ziV9Q0qhN7Oo7NMBMenK8WfcFJGlEs +DrZoe4ZXws9BwArgzny5zZzJBaWod0nFaJ30Jj5A0S0GyiKAiOt2rzuFNIoEqiy9aSa/rqF APQR7P3ocuY9yZsHi9Sr5vNQrQA9E1qk/iERvL2YTA0QAWSeNoD0YWY7qr5QoSQofwhmkGYf UuCgmgjEPtztIVXrmxfx6FAx+/rr2ynYfMGwy3oLd9AhIC937NYoMxsBVsc7Tf7damWDanjH rrcuNYm9zXayrPcANmjgHAAAAAAAAA== --------------ms000109040804090309020609--

1 0

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 14 Mar '14

14 Mar '14

I'm still looking for a resolution to the issue of the rewrite module interfering with a search that does not use the rewrite module. The behavior has not changed in the intervening updates. We are running 2.4.39, and simply referencing rwm overlay rwm returns no search results at all, if an attribute is specified for the search. Specifying no attributes returns all of the allowed attributes. Commenting the line above permits the specified attribute to be returned, as expected. The rewrite module should have no interaction with the search whatsoever, since no rewrite has been specified. Instead, it appears that the rwm intercepts the returned results and somehow "loses" all of the attributes when the search specifies a specific attribute. When no attribute is specified in the search, rwm quietly stays out of the way and lets all of the returned attributes proceed to the frontend. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7817) Wrong if condition for string length
by flo＠geekplace.eu 11 Mar '14

11 Mar '14

I just got a report [1] that the patch is incomplete, because authzid is used to calculate A1 value of the response (RFC2831 2.1.2.1). Stay tuned for an updated version. 1: https://github.com/Flowdalic/asmack/commit/2b4d004fe5a7b4224380a32658ff2056…

1 0

(ITS#7819) jldap DigesetMD5SaslClient is using m_serverName for digest-uri, when it should be use m_digestURI instead
by flo＠geekplace.eu 11 Mar '14

11 Mar '14

Full_Name: Florian Schmaus Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.188.31.107) com.novell.sasl.client.DigestMD5SaslClient is using a hard-coded prefix "ldap/" concatenated with 'm_ServerName' as value for the 'digest-uri' attribute in the SASL response. The correct value for 'digest-uri' is 'm_digestURI'. This would make the code ldap agnostic and re-useable for other purposes (e.g. XMPP), while still being able to perform ldap auth. See the following patch: --- a/com/novell/sasl/client/DigestMD5SaslClient.java 2009-12-07 19:14:10.000000000 +0100 +++ b/com/novell/sasl/client/DigestMD5SaslClient.java 2009-12-07 19:19:07.000000000 +0100 @@ -673,8 +673,8 @@ digestResponse.append("00000001"); //nounce count digestResponse.append(",qop="); digestResponse.append(m_qopValue); - digestResponse.append(",digest-uri=\"ldap/"); - digestResponse.append(m_serverName); + digestResponse.append(",digest-uri=\""); + digestResponse.append(m_digestURI); digestResponse.append("\",response="); digestResponse.append(response); digestResponse.append(",charset=utf-8,nonce=\"");

1 0

Re: (ITS#7817) Wrong if condition for string length
by quanah＠zimbra.com 11 Mar '14

11 Mar '14

--On Tuesday, March 11, 2014 5:31 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, March 11, 2014 2:03 PM +0000 fschmaus(a)gmail.com wrote: > >> --bcaec53969d8ce043204f45455b2 >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Of course the if condition for string length should be '>0' not '>=0'. > > Can you expand upon your report? What source code, for example, you're > referring to? This is a bit vague. Never mind. ;) Your reply came through like a new ITS. :P --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7817) Wrong if condition for string length
by quanah＠zimbra.com 11 Mar '14

11 Mar '14

--On Tuesday, March 11, 2014 2:03 PM +0000 fschmaus(a)gmail.com wrote: > --bcaec53969d8ce043204f45455b2 > Content-Type: text/plain; charset=ISO-8859-1 > > Of course the if condition for string length should be '>0' not '>=0'. Can you expand upon your report? What source code, for example, you're referring to? This is a bit vague. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7817) Wrong if condition for string length
by fschmaus＠gmail.com 11 Mar '14

11 Mar '14

--bcaec53969d8ce043204f45455b2 Content-Type: text/plain; charset=ISO-8859-1 Of course the if condition for string length should be '>0' not '>=0'. --bcaec53969d8ce043204f45455b2 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr">Of course the if condition for string length should be '>0' not '>=0'.</div> --bcaec53969d8ce043204f45455b2--

1 0

(ITS#7818) err=52 - unsuccessful bind due to lack of unbind
by maciej.uhlig＠us.edu.pl 11 Mar '14

11 Mar '14

Full_Name: Maciej Uhlig Version: 2.4.39 OS: CentOS release 6.5 (Final) URL: http://usnet.us.edu.pl/files/openldap/err52.txt Submission from: (NULL) (155.158.97.72) There are two OpenDJ servers and one OpenLDAP server. OpenLDAP server acts as a proxy to OpenDJ servers. OpenLDAP server is used by Dovecot mailbox server (here LDAP client) for user authentication. /---OpenDJ1 Dovecot---OpenLDAP \---OpenDJ2 OpenLDAP server runs 2.4.39 software. The problem is observed during OpenLDAP and OpenDJ servers interaction. Users can't send their mail. Dovecot server logs "ldap_bind() failed: Server is unavailable". OpenLDAP server logs "err=52". Restart of OpenLDAP server is required to resume normal operation. Analysis of OpenDJ log shows: - conn=40822 (correct) takes not more than one second - conn=40823 (incorrect) takes more than eleven minutes (it persists until OpenLDAP server is stopped) Analysis of OpenLDAP log shows: - op=29970 (conn=40822 in OpenDJ server) ends with err=0 - op=29972 (conn=40823 in OpenDJ server) ends with err=0 - op=29976 (not seen in OpenDJ server) ends with err=52 - similarly op=29979 and all subsequent end with err=52 Looks like OpenLDAP server doesn't unbind (eleven minutes above) from OpenDJ server. Instead it tries to make next bind which is unsuccesful (err=52).

1 0

(ITS#7817) jldap DigesetMD5SaslClient is using authzid for username when it should use authcid
by flo＠geekplace.eu 10 Mar '14

10 Mar '14

Full_Name: Florian Schmaus Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.217.98.14) The openldap-jldap's com.novell.sasl.cient.DigestMD5SaslClient is using authorization id (authzid) as value for the username. But the relevant RFC2831 states in section 2.1.2 that there is an extra attribute 'authzid' when assembling the response. The value of username should use m_name (the authcid) and the response should only add the authzid if it's set (Note that authzid is *optional*). --- a/com/novell/sasl/client/DigestMD5SaslClient.java +++ b/com/novell/sasl/client/DigestMD5SaslClient.java @@ -661,7 +661,7 @@ public class DigestMD5SaslClient implements SaslClient true); digestResponse.append("username=\""); - digestResponse.append(m_authorizationId); + digestResponse.append(m_name); if (0 != m_realm.length()) { digestResponse.append("\",realm=\""); @@ -679,8 +679,12 @@ public class DigestMD5SaslClient implements SaslClient digestResponse.append(response); digestResponse.append(",charset=utf-8,nonce=\""); digestResponse.append(m_dc.getNonce()); + if (m_authorizationId != null && m_authorizationId.length() >= 0) + { + digestResponse.append("\",authzid=\""); + digestResponse.append(m_authorizationId); + } digestResponse.append("\""); - return digestResponse.toString(); }

1 0

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

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs