openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8070) test023 failures
by hyc＠symas.com 04 Mar '15

04 Mar '15

richton(a)nbcs.rutgers.edu wrote: > On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote: > >>> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 >>> for me, recently) but seems to be more than a one-off... >>> >> >> Confirmed with Howard this is a timing dependent script, and it's >> affected by recent changes to the code base. refint used to do all its >> work inline, but now it uses a separate thread, so on a slow enough >> machine, it may not be done by the time the script runs its ldapsearch. >> >> I.e., doesn't appear to be a code bug. The test needs tweaking at some >> point to add some sleeps to handle this. :P > > Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference > from your earlier email)? That one failed after 80 runs. The refint behavior (using a separate thread) is not a recent change - that was made in 2006. But the test script is even older. -- -- 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#8070) test023 failures
by michael＠stroeder.com 04 Mar '15

04 Mar '15

This is a cryptographically signed message in MIME format. --------------ms080008030100090401070303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > Confirmed with Howard this is a timing dependent script, and it's affec= ted=20 > by recent changes to the code base. refint used to do all its work=20 > inline, but now it uses a separate thread, so on a slow enough machine,= it=20 > may not be done by the time the script runs its ldapsearch. Hmm, I'm not convinced that it really makes sense to have slapo-refint do= ing its job asynchronously. I'm very much concerned about data consistency w= ith sync jobs relying on e.g. group membership being immediately updated etc.= I'd rather prefer to have slow write operations than having inconsistent references. Can this be made configurable? Please...! Also how about impact on transaction handling in upcoming 2.5.x? Ciao, Michael. --------------ms080008030100090401070303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAzMDQwOTI0MDNaMCMGCSqGSIb3DQEJBDEWBBSHnyxsul9L wIajeXJzOyHvpTlhrTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEASmg+fUZV O5b1dwe+th1NR18cxrOdeA4DYxQZ4EaGtSnYM/arTV4j1TrREnClciZa7LHdpC6AoihZG82D bxg6IKDShd/N3gZI8i7ghR+tTh4mE6Su8dyaJwekGRSnMg57mzEfq/tZ35uZlfoi8GwvkYwH P8R2LGYp1ffU65aURmq1qp949McoFae9QqMU5+mJsP2vDoNcIAA2+xSbehAIRQpLjN6qzlHM Oq+34mAhE95YtsTrkYW954zonBRooHHTNJLj4R62dSVelsfHindMu7byStYacL4eF8Xmrrb7 txsHofGRZrlJeztVHU26UwBMWCSM825dkEK79LAW1G8oBQAAAAAAAA== --------------ms080008030100090401070303--

1 0

Re: (ITS#8070) test023 failures
by richton＠nbcs.rutgers.edu 04 Mar '15

04 Mar '15

On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote: >> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 >> for me, recently) but seems to be more than a one-off... >> > > Confirmed with Howard this is a timing dependent script, and it's > affected by recent changes to the code base. refint used to do all its > work inline, but now it uses a separate thread, so on a slow enough > machine, it may not be done by the time the script runs its ldapsearch. > > I.e., doesn't appear to be a code bug. The test needs tweaking at some > point to add some sleeps to handle this. :P Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference from your earlier email)? That one failed after 80 runs.

1 0

Re: (ITS#8070) test023 failures
by quanah＠zimbra.com 04 Mar '15

04 Mar '15

--On Monday, March 02, 2015 10:17 PM +0000 richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 > OS: Linux > URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > Seeing occasional failures on test023 using mdb. Takes a few runs (~30 > for me, recently) but seems to be more than a one-off... > Confirmed with Howard this is a timing dependent script, and it's affected by recent changes to the code base. refint used to do all its work inline, but now it uses a separate thread, so on a slow enough machine, it may not be done by the time the script runs its ldapsearch. I.e., doesn't appear to be a code bug. The test needs tweaking at some point to add some sleeps to handle this. :P --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8070) test023 failures
by quanah＠zimbra.com 03 Mar '15

03 Mar '15

--On Monday, March 02, 2015 10:17 PM +0000 richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 > OS: Linux > URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > Seeing occasional failures on test023 using mdb. Takes a few runs (~30 > for me, recently) but seems to be more than a one-off... Doesn't happen for me with 4129e246a85a6d1f0033466ed2c7fb51c6dee508 (Feb 6th), so it is something recently introduced. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8070) test023 failures
by richton＠nbcs.rutgers.edu 02 Mar '15

02 Mar '15

Full_Name: Aaron Richton Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 OS: Linux URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 Submission from: (NULL) (128.6.31.135) Seeing occasional failures on test023 using mdb. Takes a few runs (~30 for me, recently) but seems to be more than a one-off...

1 0

(ITS#8069) MDb library patch: Use explicit Windows API functions for char* strings
by pmedvedev＠gmail.com 28 Feb '15

28 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) Most Windows API functions such as CreateFile(), CreateMutex(), OpenMutex() that accept string arguments, are defined with suffix W or A for appropriate wchar_t* or char* strings, depending of _UNICODE preprocessor define. Calling explicit functions with A suffix would eliminate compile errors when _UNICODE is defined. As a further enhancement, I think path argument encoding should be documented (probably UTF-8?) for such functions as mdb_env_open(), mdb_env_copy(), mdb_env_copy2(), and mdb_env_get_path(). This prevent possible problems with non-latin characters in path names on Windows. In this case, LMDB implementation on Windows should perform path conversion to UTF-16 and explicit call to CreateFileW() in mdb_env_open() and mdb_env_copy2() functions. --- libraries/liblmdb/mdb.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a54ce83..a669da6 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -1409,7 +1409,7 @@ mdb_strerror(int err) ; } buf[0] = 0; - FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | + FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, err, 0, ptr, sizeof(buf), (va_list *)pad); return ptr; @@ -4413,7 +4413,7 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) off_t size, rsize; #ifdef _WIN32 - env->me_lfd = CreateFile(lpath, GENERIC_READ|GENERIC_WRITE, 909env->me_lfd = CreateFileA(lpath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); #else @@ -4517,9 +4517,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int xcxcl) mdb_hash_enc(&val, encbuf); sprintf(env->me_txns->mti_rmname, "Global\\MDBr%s", encbuf); sprintf(env->me_txns->mti_wmname, "Global\\MDBw%s", encbuf); - env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) unsigned short vals[2] = {1, 1}; @@ -4569,9 +4569,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) goto fail; %%D #ifdef _WIN32 - env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex =pepenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) semid = env->me_txns->mti_semid; @@ -4686,7 +4686,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode len = OPEN_ALWAYS; } mode = FILE_ATTRIBUTE_NORMAL; - env->me_fd = CreateFile(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, + env->me_fd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode, NULL); #else if (F_ISSET(flags, MDB_RDONLY)) @@ -4716,7 +4716,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode */ #ifdef _WIN32 len = OPEN_EXISTING; - % e9env->me_mfd = CreateFile(dpath, oflags, + env->me_mfd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode | FILE_FLAG_WRITE_THROUGH, NULL); #else @@ -8981,7 +8981,7 @@ mdb_env_copy2(MDB_env *env, const char *path, unsigned int flags) * already in the OS cache. */ #ifdef _WIN32 - newfd = CreateFile(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, + newfd = CreateFileA(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_FLAG_NO_BUFFERING|FILE_FLAG_WRITE_THROUGH, NULL); #else newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); -- 1.9.5.msysgit.0

1 0

(ITS#8068) MDB library patch: Using IsWindowsVersionOrGreater() instead of obsolete GetVersion()
by pmedvedev＠gmail.com 28 Feb '15

28 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) --- libraries/liblmdb/mdb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 65293f4..a54ce83 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -239,6 +239,7 @@ union semun { #endif #ifdef _WIN32 +#include <VersionHelpers.h> #define MDB_USE_HASH 1 #define MDB_PIDLOCK 0 #define THREAD_RET DWORD @@ -3998,8 +3999,7 @@ mdb_env_open2(MDB_env *env) #ifdef _WIN32 /* See if we should use QueryLimited */ - rc = GetVersion(); - if ((rc & 0xff) > 5) + if (IsWindowsVersionOrGreater(6, 0, 0)) env->me_pidquery = MDB_PROCESS_QUERY_LIMITED_INFORMATION; else env->me_pidquery = PROCESS_QUERY_INFORMATION; -- 1.9.5.msysgit.0

1 0

(ITS#8067) MDB library patch: Added ssize_t typedef for Visual C++
by pmedvedev＠gmail.com 28 Feb '15

28 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) --- libraries/liblmdb/mdb.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 984a5bd..65293f4 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c%%0 @@ -96,7 +96,13 @@ extern int cacheflush(char *addr, int nbytes, int cache); #include <stdlib.h> #include <string.h> #include <time.h> + +#ifdef _MSC_VER +#include <io.h> +typedef SSIZE_T ssize_t; +#else #include <unistd.h> +#endif % A #if defined(__sun) || defined(ANDROID) /* Most platforms have posix_memalign, older may only have memalign */

1 0

Re: (ITS#8066) mdb_load truncates long values when resizing buffer
by hyc＠symas.com 26 Feb '15

26 Feb '15

catwell(a)archlinux.us wrote: > Full_Name: Pierre Chapuis > Version: master > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.238.40.212) > > > Description: > > Starting from 2048, the first input line larger than any power of two N > is truncated to N-1. This results in truncated values in the database. Thanks for the report. Fixed now in mdb.master > > Explanation: > > In the code that resizes the input buffer, fgets() is used. > fgets(*, n, *) reads a maximum of n-1 characters and 0-terminates > the string. When the next chunk is read, the '\0' remains in the > string. Later, strlen() is used and the string is truncated. > > Proposed fix: > > A patch against the current OpenLDAP master llllows. > > --- > > libraries/liblmdb/mdb_load.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c > index f626692..e86b6fd 100644 > --- a/libraries/liblmdb/mdb_load.c > +++ b/libraries/liblmdb/mdb_load.c > @@ -218,7 +218,7 @@ badend: > } > c1 = buf->mv_data; > c1 += buf->mv_size; > - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) {D%D > + if (fgets((char *)c1-1, buf->mv_size+1, stdin) == NULL) { > Eof = 1; > badend(); > return EOF; > > --- > > > -- -- 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