CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_07
dragon

FIXED IN:
1.4.2_07

INTEGRATED IN:
1.4.2_07


                                     

EVALUATION

Will investigate and supply fix if necessary for 1.5.1
###@###.### 2004-04-12


The lines in ./src/windows/native/java/lang/ProcessImpl_md.c  Lines 188-191:
char msg[1024];
jio_snprintf(msg, 1024, "CreateProcess: %s error = %d", pcmd, GetLastError());
JNU_ThrowByName(env, "java/io/IOException", msg);

suggests that JNU_ThrowByName is not being passed the command path in modified
UTF-8 format as JNU_ThrowByName expects and this may be leading to the garbled
error message propogated by the JNU_ThrowByName JNI call.
This looks similar to some other recent bugs (eg, 4934415) where OS generated
error messages which are locale sensitive are not correctly encoded when
the JNI exception printing code is called. The suggested fix would be to use a
similar approach already successfully used to address the similar bug : 4934415

I've looked at MS932 and shift_jis Java charset implementations in 1.4.x, 1.5.0
and the characters for which the garbling occurs are fully roundtrippable using
those charset coders so the code which needs to be examined closer is the native
impl for java.lang.Process and how it handles the propagation of OS generated
error msg text
###@###.### 2004-04-19

The problem is that multibyte strings need to be converted to Objects,
and the object thrown as the exception (JNU_NewObjectByName) Otherwise the
strings will get mangled!

###@###.### 25/Jun/04
###@###.### 2004-06-25

I agree with Ian's analysis above.  A more compact code snippet for
testing might look like this:

static void test(String command) throws Exception {
    try {Runtime.getRuntime().exec(command);}
    catch (Exception e) {
        System.out.println(new String(e.getMessage().getBytes("ISO-8859-1")));}}

There are two encoding issues here - the encoding of the filename,
which we should never get wrong, seeing as it's available to Java
as a string before, and the encoding of the OS error message, as
returned by strerror or moral equivalents.

A good strategy for resolving this might be to code up a
JDK-private method 
String strerror(int errno)
which would convert the errno into a string using the appropriate
encoding.  JNI code that detects an error might typically just
pass back an integer, and let Java code deal with converting that to
a proper exception with filename and translated "file not found"
or whatever.

A good strategy for testing this sort of thing is to make sure that
the message retrieved using a mechanism such as the above does not
contain the replacement character '\ufffd' or perhaps '?' (although
that one might occur in a real-world error message).

###@###.### 2004-09-02
                                     

SUGGESTED FIX

% sccs diffs -r1.15 Win32Process_md.c

------- Win32Process_md.c -------
2c2
<  * %W% %E%
---
>  * @(#)Win32Process_md.c      1.16 04/06/25
174a175
>         jobject x;
175a177,178
>         jstring err_string = NULL;
>
179,182c182,195
<       jio_snprintf(msg, 1024,
<                    "CreateProcess: %s error=%d", cmd, GetLastError());
<       JNU_ThrowByName(env, "java/io/IOException", msg);
<       goto cleanup;
---
>         jio_snprintf(msg, 1024,
>             "CreateProcess: %s error=%d", cmd, GetLastError());
>         err_string = JNU_NewStringPlatform(env, msg);
>
>         x = JNU_NewObjectByName(env,"java/io/IOException",
>             "(Ljava/lang/String;)V",err_string);
>
>         if (x != NULL) {
>            (*env)->Throw(env, x);
>         }
>         else { // Fall back and print something out.
>            JNU_ThrowByName(env, "java/io/IOException", msg);
>         }
>         goto cleanup;
%
###@###.### 2004-06-25