(ITS#8069) MDb library patch: Use explicit Windows API functions for char* strings
by pmedvedev@gmail.com
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
8 years, 3 months
(ITS#8068) MDB library patch: Using IsWindowsVersionOrGreater() instead of obsolete GetVersion()
by pmedvedev@gmail.com
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
8 years, 3 months
(ITS#8067) MDB library patch: Added ssize_t typedef for Visual C++
by pmedvedev@gmail.com
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 */
8 years, 3 months
Re: (ITS#8066) mdb_load truncates long values when resizing buffer
by hyc@symas.com
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/
8 years, 3 months
Re: (ITS#8066) mdb_load truncates long values when resizing buffer
by catwell@archlinux.us
For what it's worth, here is a slightly better patch.
The previous one would start the strlen() one character
too far. I don't think it would have much consequence
in practice, but this should be safer.
---
libraries/liblmdb/mdb_load.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c
index f626692..960d23d 100644
--- a/libraries/liblmdb/mdb_load.c
+++ b/libraries/liblmdb/mdb_load.c
@@ -216,9 +216,8 @@ badend:
prog, lineno);
return EOF;
}
- c1 = buf->mv_data;
- c1 += buf->mv_size;
- if (fgets((char *)c1, buf->mv_size, stdin) == NULL) {
+ c1 = buf->mv_data + buf->mv_size - 1;
+ if (fgets((char *)c1, buf->mv_size+1, stdin) == NULL) {
Eof = 1;
badend();
return EOF;
--
Pierre Chapuis
8 years, 3 months
(ITS#8066) mdb_load truncates long values when resizing buffer
by catwell@archlinux.us
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.
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;
---
8 years, 3 months
Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by leo@yuriev.ru
Yes, Howard you are right.
In our CI-process 'make test' crashes only for 2.5 branch.
I was noted 2.4 in the ITS, it's my mistake.
To fix this bug seems a de-registration should be provided by monitor-backend.
2015-02-25 17:47 GMT+03:00 Howard Chu <hyc(a)symas.com>:
> pierangelo.masarati(a)polimi.it wrote:
>>
>> back-monitor was designed before back-config, without considering the
>> possibility of database removal during regular operations. There might
>> be several flaws of that kind.
>
>
> Removal is not supported in 2.4. All of that is work-in-progress for 2.5.
> Patches welcome, but this is not a 2.4 bug.
>
>
>> My suggestion is that back-monitor is never shut down (it should be
>> inhibited) except at slapd shutdown. Meanwhile, the code initialization
>> and shutdown could be redesigned to properly handle those cases.
>>
>> On 25/02/2015 15:18, leo(a)yuriev.ru wrote:
>>>
>>> Full_Name: Leonid Yuriev
>>> Version: 2.4-HEAD
>>> OS: RHEL7
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (31.130.36.33)
>>>
>>>
>>> Monitor-backend shutdown code could call a callback from registered
>>> subsystem
>>> after it is already destroyed.
>>>
>>> For instance, currently ldap-backend frees its own registered context
>>> (lmi_mss
>>> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be
>>> called.
>>>
>>> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend
>>> database is configured and such freed context will be overwrited.
>>>
>>> This bug could be reproduced by a filling-memory-with-non-zero before
>>> calling
>>> free() from glibc.
>>>
>>>
>>>
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 3 months
(ITS#8065) autogroup+accesslog problems
by hyc@openldap.org
Full_Name: Howard Chu
Version: 2.4
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (199.188.194.66)
Submitted by: hyc
The autogroup overlay doesn't work well with accesslog. This is the same problem
we've had in the past with e.g. memberof, refint, and other overlays that do
internal modifications as a side-effect of a main user operation. In particular,
autogroup's internal ops use the same timestamp as the original op, so accesslog
will log one of these internal ops and then none of the others because it uses
the timestamp for the RDN of its log entries, and that RDN is already in use.
This means the main user onevever gets logged, nor do any side-effect
modifications after the first one.
The solution in previous cases has been to turn off all accesslog activity for
internal operations. In the case of accesslog used for replication, accesslog
shoulononly log the main user operation, and it's up to replicas to perform the
same internal operations themselves as needed.
8 years, 3 months
Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by hyc@symas.com
pierangelo.masarati(a)polimi.it wrote:
> back-monitor was designed before back-config, without considering the
> possibility of database removal during regular operations. There might
> be several flaws of that kind.
Removal is not supported in 2.4. All of that is work-in-progress for 2.5. Patches welcome, but this is not a 2.4 bug.
> My suggestion is that back-monitor is never shut down (it should be
> inhibited) except at slapd shutdown. Meanwhile, the code initialization
> and shutdown could be redesigned to properly handle those cases.
>
> On 25/02/2015 15:18, leo(a)yuriev.ru wrote:
>> Full_Name: Leonid Yuriev
>> Version: 2.4-HEAD
>> OS: RHEL7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (31.130.36.33)
>>
>>
>> Monitor-backend shutdown code could call a callback from registered subsystem
>> after it is already destroyed.
>>
>> For instance, currently ldap-backend frees its own registered context (lmi_mss
>> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called.
>>
>> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend
>> database is configured and such freed context will be overwrited.
>>
>> This bug could be reproduced by a filling-memory-with-non-zero before calling
>> free() from glibc.
>>
>>
>>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 3 months
Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by pierangelo.masarati@polimi.it
back-monitor was designed before back-config, without considering the
possibility of database removal during regular operations. There might
be several flaws of that kind.
My suggestion is that back-monitor is never shut down (it should be
inhibited) except at slapd shutdown. Meanwhile, the code initialization
and shutdown could be redesigned to properly handle those cases.
On 25/02/2015 15:18, leo(a)yuriev.ru wrote:
> Full_Name: Leonid Yuriev
> Version: 2.4-HEAD
> OS: RHEL7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (31.130.36.33)
>
>
> Monitor-backend shutdown code could call a callback from registered subsystem
> after it is already destroyed.
>
> For instance, currently ldap-backend frees its own registered context (lmi_mss
> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called.
>
> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend
> database is configured and such freed context will be overwrited.
>
> This bug could be reproduced by a filling-memory-with-non-zero before calling
> free() from glibc.
>
>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
8 years, 3 months