JDK-4492822 : jvm exec's itself twice if -d64 is used -- breaks Analyzer workaround
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-08-16
  • Updated: 2013-07-16
  • Resolved: 2002-11-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description
If I run the JVM on a 32-bit code, it resets its LD_LIBRARY_PATH, and
then exec's itself to use the new path.  We implemented a workaround
in the analyzer, to collect data from the JVM after its exec.

When -d64 is specified, jvm first exec's its 64-bit version, and then resets
its LD_LIBRARY_PATH, and exec's again.  We collect data on the first
64-bit exec, which is useless to the user, and the second exec's JVM fails
because the profiling timer ticks.  We will fix that in our code, so it
won't fail, but we still won't get the data from the "real" jvm execution.

Can JVM be fixed to always do one exec: if it's to be 32-bit set LD_LIBRARY_PATH
and then exec; if it's to be 64-bit, set LD_LIBRARY_PATH, and then exec
the 64-bit version.

We can't really workaround this without parsing the user's java arguments,
and figuring out how many exec's are expected, and I really think it's a bad
idea to have us need to understand java's arguments.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07
14-06-2004

SUGGESTED FIX See code diffs in bug 4731666, specifically in src/solaris/java_md.c, function SetLibraryPath.
11-06-2004

PUBLIC COMMENTS ...
10-06-2004

EVALUATION This certainly is a result of the launcher rewrite; one exec is to invoke the 64-bit executable and the second is to get the correct LD_LIBRARY_PATH. It is indeed possible to do it all in one exec, but making that change would be too disruptive at this stage of the release. ###@###.### 2001-09-10
10-09-2001