PM29739: STORAGE GROWTH IN NATIVE MEMORY OF X18 BYTE ALLOCATIONS WHEN CREATING JAVACORE DUMPS.
Closed as program error.
Creating a javacore programmatically, such as when calling com.ibm.jvm.Dump.JavaDump() in a class, or by requesting them through WebSphere via the modify command, a storage growth in native memory of x18 bytes is seen in SP2 K8. The storage will contain the string IBM-1047 in both ascii and ebcdic . The storage is not freed until the jvm terminates. The native stack where the allocations occur: CEEVGHPH 0D5B6A70 +00000000 etoa_nl_langinfo 22840AE8 +00000086 iconv_get 7CB068C0 +0000001E parse_catalog 7CB09740 +0000030A j9nls_lookup_message 7CB0AC00 +00000484 j9nls_vprintf 7CB0B5B0 +00000024 j9nls_printf 7CB0B108 +0000003C reportDumpRequest 7CA05FF8 +00000062 JavaCoreDumpWriter::JavaCoreDumpWriter 7CA21BC0 +000000EA runJavadump 7CA29668 +00000018
the workaround is to NOT capture javacores programmatically. Console dumps or svc dumps can be captured if dumps are needed
The problematic code path resulted in functions that were converting from EBCDIC to ASCII and back to EBCDIC, instead use the original EBCDIC value.
This defect will be fixed in: 5.0.0 SR12 FP5 6.0.0 SR9 FP2 . The JVM has been updated to avoid the calls to e2a_string() and a2e_string(). . To obtain the fix: Install build 20110111 or later
Reported component name
JAVA 5 Z/OS 31
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
JAVA 5 Z/OS 31
Fixed component ID
Applicable component levels
Translate this page: