Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
-
Win32
-
Unknown
Description
At the very end of a run of all of the LUNI tests (whether run by themselves or as part of the larger test suite) the runtime terminates in a rather nasty way and leaves behind some pretty substantial core dump files. This is the kind of error information you might see in your console ...
Thread: main (priority 5) (LOCATION OF ERROR)
NATIVE com/ibm/icu4jni/converters/NativeConverter.resetCharToByte(J)V
00000004 com/ibm/icu4jni/charset/CharsetEncoderICU.implReset()V
00000006 java/nio/charset/CharsetEncoder.reset()Ljava/nio/charset/CharsetEncoder;
0000000d
java/nio/charset/CharsetEncoder.encode(Ljava/nio/CharBuffer;)Ljava/nio/ByteBuffer;
0000000d java/nio/charset/Charset.encode(Ljava/nio/CharBuffer;)Ljava/nio/ByteBuffer;
00000013 java/lang/String.getBytes()[B
00000010 com/ibm/oti/util/Util.getBytes(Ljava/lang/String
[B
00000010 java/io/File.properPath(Z)[B
0000001f java/io/File.isDirectory()Z
...etc ...
This is being caused by a nasty interaction between one of the test case methods that calls System.runFinalizersOnExit(true) and the ICU4JNI libraries that close character converter handles in a finalize() method. The result is that at VM shutdown time, the ICU4JNI charset encoder's finalize() is called and then later on in the shutdown sequence an attempt is made to use the now invalid handle. The short term fix is to ensure that the test suite does not force all finalize() methods to be run at shutdown - this will at least save a number of core files from eating up your disk. Longer term, we wil probably have to look at the ICU4JNI source itself to see if it can be made guard against attempted usage of its converter handle after it has become invalid - something which should really only happen in the scenario described above.
One line patch to follow.
Best regards,
George