-
Bug
-
Resolution: Fixed
-
P4
-
7
-
b04
-
generic
-
solaris
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2184791 | 7 | Vladimir Kozlov | P4 | Closed | Fixed | b75 |
JDK-2190002 | 6u21 | Vladimir Kozlov | P4 | Resolved | Fixed | b01 |
JDK-2190307 | mvm-hs16 | Karen Kinnear | P3 | Resolved | Fixed | team |
The libjvm.so under jre/lib/<arch> is supposed to be a symbolic link to the real libjvm.so file under the client subdirectory.
However, this is not the case when zip bundles are built for JPRT using make/jprt.gmk.
We observed the following crashes during VM testing on Solaris:
fdc8c06c JVM_NativePath (feffa1f0, fe257170, 21170, fe246474, 5a9fd8, 21000) + 48
fe47cca4 ZIP_Get_From_Cache (feffa748, feffa73c, 0, 0, 880b8, 33d8) + 80
fe4716d4 ZIP_Open_Generic (feffa748, feffa73c, 0, 0, 0, 7f8d92) + 20
fe4716a4 ZIP_Open (feffa748, feffa73c, fe471690, 44304, fee53c90, 43670) + 14
fea49130 __1cLClassLoaderXcreate_class_path_entry6FpcnEstat_ppnOClassPathEntry_b_v_ (28bb0, 16cc0, feffacbc, 26400, fee572e7, 9c90) + 308
fea48968 __1cSLazyClassPathEntryLopen_stream6Mpkc_pnPClassFileStream__ (28b08, 26940, fee53d38, 1, 9cac, 0) + 70
fe8fad24 __1cLClassLoaderOload_classfile6FnMsymbolHandle_pnGThread__nTinstanceKlassHandle__ (feffaf00, feffaefc, 26400, 28b08, 26c14, fee4a000) + 168
fe8c4ec0 __1cQSystemDictionaryTload_instance_class6FnMsymbolHandle_nGHandle_pnGThread__nTinstanceKlassHandle__ (feffaffc, feffaff8, 26400, 26400, feffaff4, fee5f2b0) + 5c
fe8c4618 __1cQSystemDictionarybEresolve_instance_class_or_null6FnMsymbolHandle_nGHandle_2pnGThread__pnMklassOopDesc__ (d000, feffb0fc, feffb0f8, 1da, 26400, fee4a000) + 81c
fe8c77f8 __1cQSystemDictionaryPresolve_or_null6FnMsymbolHandle_nGHandle_2pnGThread__pnMklassOopDesc__ (feffb18c, feffb188, fee706c0, 0, 0, 0) + ac
fec997c4 __1cQSystemDictionaryPresolve_or_fail6FnMsymbolHandle_nGHandle_2bpnGThread__pnMklassOopDesc__ (feffb1f8, feffb1f4, feffb1f0, 1, 26400, f74011d0) + 2c
fe8c312c __1cQSystemDictionarybCinitialize_preloaded_classes6FpnGThread__v_ (26400, fee706c0, 1, fee4a000, fee706b8, 26400) + 4c
fe8c1724 __1cIUniverseHgenesis6FpnGThread__v_ (26400, 21e18, fee62c00, fee62d24, fee62c00, 0) + c44
fe8c0824 __1cOuniverse2_init6F_v_ (fb832000, 26a28, 26a40, 21e18, 7bc00, fee0f000) + 14
fe886374 __1cMinit_globals6F_i_ (0, ff1, 7f8d92, feffbcd8, fee4a000, 14000) + 10c
fecb6d90 __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_ (185f0, feffbeab, 26400, fee625e8, cb4, fee4a000) + 254
fe87d368 JNI_CreateJavaVM (21ab4, feffbf30, feffbf20, fee5f2a0, 5ccd50, 13) + bc
00010d4c initJVM (1d, 11548, ff185c04, 71f5c, ff180658, 1d) + 64
00011058 somethr (0, feffc000, fc000, 11030, 0, 0) + 28
However, this is not the case when zip bundles are built for JPRT using make/jprt.gmk.
We observed the following crashes during VM testing on Solaris:
fdc8c06c JVM_NativePath (feffa1f0, fe257170, 21170, fe246474, 5a9fd8, 21000) + 48
fe47cca4 ZIP_Get_From_Cache (feffa748, feffa73c, 0, 0, 880b8, 33d8) + 80
fe4716d4 ZIP_Open_Generic (feffa748, feffa73c, 0, 0, 0, 7f8d92) + 20
fe4716a4 ZIP_Open (feffa748, feffa73c, fe471690, 44304, fee53c90, 43670) + 14
fea49130 __1cLClassLoaderXcreate_class_path_entry6FpcnEstat_ppnOClassPathEntry_b_v_ (28bb0, 16cc0, feffacbc, 26400, fee572e7, 9c90) + 308
fea48968 __1cSLazyClassPathEntryLopen_stream6Mpkc_pnPClassFileStream__ (28b08, 26940, fee53d38, 1, 9cac, 0) + 70
fe8fad24 __1cLClassLoaderOload_classfile6FnMsymbolHandle_pnGThread__nTinstanceKlassHandle__ (feffaf00, feffaefc, 26400, 28b08, 26c14, fee4a000) + 168
fe8c4ec0 __1cQSystemDictionaryTload_instance_class6FnMsymbolHandle_nGHandle_pnGThread__nTinstanceKlassHandle__ (feffaffc, feffaff8, 26400, 26400, feffaff4, fee5f2b0) + 5c
fe8c4618 __1cQSystemDictionarybEresolve_instance_class_or_null6FnMsymbolHandle_nGHandle_2pnGThread__pnMklassOopDesc__ (d000, feffb0fc, feffb0f8, 1da, 26400, fee4a000) + 81c
fe8c77f8 __1cQSystemDictionaryPresolve_or_null6FnMsymbolHandle_nGHandle_2pnGThread__pnMklassOopDesc__ (feffb18c, feffb188, fee706c0, 0, 0, 0) + ac
fec997c4 __1cQSystemDictionaryPresolve_or_fail6FnMsymbolHandle_nGHandle_2bpnGThread__pnMklassOopDesc__ (feffb1f8, feffb1f4, feffb1f0, 1, 26400, f74011d0) + 2c
fe8c312c __1cQSystemDictionarybCinitialize_preloaded_classes6FpnGThread__v_ (26400, fee706c0, 1, fee4a000, fee706b8, 26400) + 4c
fe8c1724 __1cIUniverseHgenesis6FpnGThread__v_ (26400, 21e18, fee62c00, fee62d24, fee62c00, 0) + c44
fe8c0824 __1cOuniverse2_init6F_v_ (fb832000, 26a28, 26a40, 21e18, 7bc00, fee0f000) + 14
fe886374 __1cMinit_globals6F_i_ (0, ff1, 7f8d92, feffbcd8, fee4a000, 14000) + 10c
fecb6d90 __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_ (185f0, feffbeab, 26400, fee625e8, cb4, fee4a000) + 254
fe87d368 JNI_CreateJavaVM (21ab4, feffbf30, feffbf20, fee5f2a0, 5ccd50, 13) + bc
00010d4c initJVM (1d, 11548, ff185c04, 71f5c, ff180658, 1d) + 64
00011058 somethr (0, feffc000, fc000, 11030, 0, 0) + 28
- backported by
-
JDK-2190307 JPRT make file doesn't create required symbolic link to libjvm.so
- Resolved
-
JDK-2190002 JPRT make file doesn't create required symbolic link to libjvm.so
- Resolved
-
JDK-2184791 JPRT make file doesn't create required symbolic link to libjvm.so
- Closed
- relates to
-
JDK-6397622 [TESTBUG] Tests should not exit with fail status when run on wrong hardware
- Closed