JDK-5023243 : (process) Error msg on exception is not displayed correctly in Japanese on XP
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-03-30
  • Updated: 2006-03-09
  • Resolved: 2004-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_07 b01Fixed 6Fixed
Related Reports
Relates :  
JDK-6192449 - (process) Runtime.exec error message on Windows should be improved
Relates :  
JDK-5097226 - Audit use of OS strings in native code for decoding errors
Description
When Exception occurs with invalid command thru Runtime.exec(),
the error message is not displayed correctly.

REPRODUCE:
  (1) Compile the attached test program, Command.java
  
      The test program invokes invalid command thru Runtime.exec()
      in order to cause an exception.
      
  (2) Launch "java Command" on WindowsXP(Japanese)
  
  You will see the message in the attached file, "incorrect-msg.txt".
  (Please see the file on Windows XP box)
  
  Also, I attached the expected message in attached "expected-msg.txt".


CONFIGURATION :
  OS  : WinXP (SP1, Japanese)
  JDK : JDK1.5.0b43

java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b44)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b44, mixed mode, sharing)

================================================================================
Comments
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
02-10-2004
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
02-09-2004
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
25-06-2004