In native/dispatch.c, we have:
#define STR_ERROR(CODE,BUF,LEN) (strerror_r(CODE, BUF, LEN), BUF)
and then later:
if (error) {
char emsg[1024];
snprintf(msg, sizeof(msg), "[%d]%s", error, STR_ERROR(error, emsg, sizeof(emsg)));
throw_type = ELastError;
throw_msg = msg;
}
However, strerror_r exists in two very different flavors: XSI and GNU, see for instance http://unixhelp.ed.ac.uk/CGI/man-cgi?strerror.
When the GNU flavor is used, the emsg buffer will maybe not be written to and the code will therefore use uninitialized data. This is exactly what we see in practice in our Java code on Linux 32-bits with errors like:
rename(x1, x2): [2]<?L
mkdir(d1): [17]?*??_?�x?
FWIW, the Linux man page contains:
The XSI-compliant version of strerror_r() is provided if:
(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
Otherwise, the GNU-specific version is provided.
So either the code should force the use of the XSI version of strerror_r or it should conditionally define STR_ERROR to work in both cases.
In native/dispatch.c, we have:
and then later:
However, strerror_r exists in two very different flavors: XSI and GNU, see for instance http://unixhelp.ed.ac.uk/CGI/man-cgi?strerror.
When the GNU flavor is used, the emsg buffer will maybe not be written to and the code will therefore use uninitialized data. This is exactly what we see in practice in our Java code on Linux 32-bits with errors like:
FWIW, the Linux man page contains:
So either the code should force the use of the XSI version of strerror_r or it should conditionally define STR_ERROR to work in both cases.