United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6722084 : JPRT make file doesn't create required symbolic link to libjvm.so

Details
Type:
Bug
Submit Date:
2008-07-02
Status:
Resolved
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2009-11-11
Component:
hotspot
OS:
solaris
Sub-Component:
build
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs17 (b04)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
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

                                    

Comments
PUBLIC COMMENTS

Problem:
There are several annoying Nightly testing failures which
nobody fixing for years. Caused by hotspot JPRT build bundles
have normal .so libraries instead of symbolic links as in JDK.

Solution:
The fix suggested by Kelly is very simple: use -y zip option
to preserve symbolic links.
I also fixed incorrect installation of libjsig.so
in JPRT build bundles which put it into client/server
subdirectories.
                                     
2009-10-15
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/23862fc517bb
                                     
2009-10-14
EVALUATION

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.

======
                                     
2008-07-02



Hardware and Software, Engineered to Work Together