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
Posted Date : 2008-07-02 23:14:02.0

N/A

Kelly O'Hair wrote:

======

The problem is in the hotspot repository file make/jprt.gmk,
it needs to add the zip -y option on Solaris and Linux, something
like this:

diff -r 93435819dba2 make/jprt.gmk
--- a/make/jprt.gmk     Fri Jun 20 08:44:58 2008 -0700
+++ b/make/jprt.gmk     Wed Jul 02 08:56:13 2008 -0700
@@ -29,17 +29,23 @@ ifdef JPRT_BUILD_VERSION
   MILESTONE=$(JPRT_BUILD_VERSION)
 endif

+ifeq ($(OSNAME),windows)
+  ZIPFLAGS=-q
+else
+  ZIPFLAGS=-q -y
+endif
+
 jprt_build_product: all_product copy_product_jdk export_product_jdk
        ( $(CD) $(JDK_IMAGE_DIR) && \
-         $(ZIPEXE) -q -r $(JPRT_ARCHIVE_BUNDLE) . )
+         $(ZIPEXE) $(ZIPFLAGS) -r $(JPRT_ARCHIVE_BUNDLE) . )

 jprt_build_fastdebug: all_fastdebug copy_fastdebug_jdk export_fastdebug_jdk
        ( $(CD) $(JDK_IMAGE_DIR)/fastdebug && \
-         $(ZIPEXE) -q -r $(JPRT_ARCHIVE_BUNDLE) . )
+         $(ZIPEXE) $(ZIPFLAGS) -r $(JPRT_ARCHIVE_BUNDLE) . )

 jprt_build_debug: all_debug copy_debug_jdk export_debug_jdk
        ( $(CD) $(JDK_IMAGE_DIR)/debug && \
-         $(ZIPEXE) -q -r $(JPRT_ARCHIVE_BUNDLE) . )
+         $(ZIPEXE) $(ZIPFLAGS) -r $(JPRT_ARCHIVE_BUNDLE) . )

 .PHONY: jprt_build_product jprt_build_fastdebug jprt_build_debug


This problem may exist in the other repositories too.

So technically it's not a JPRT system problem, the workspace or repository
Makefiles are the ones constructing the zip bundles.

I suggest we start with filing a bug against hotspot, and maybe the jdk
too.

======
Posted Date : 2008-07-02 23:14:02.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23862fc517bb
Posted Date : 2009-10-14 22:56:17.0