Bug ID: JDK-6603919 Stackwalking crash on x86 -server with Sun Studio's collect -j on

Versions (Unresolved/Resolved/Fixed)

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.

JDK 6	JDK 7	Other
6u14Fixed	7Fixed	hs13Fixed

Stackwalking crash on x86 with Sun Studio Collector/Analyzer. I have not
tried running on Linux; all of the following are wrt Solaris on an amd64
machine (foundation.sfbay) running a 32 bit jvm.

Collector option: -j on
VM options used: -server -XX:+UseParallelGC
program: specjvm98

See related email in comments section.

The crashes go away if using -Xint or -client (but see further below),
or if collector's "-j on" option is dropped.

The crashes also appear to go away if using 7b05, which predates the
introduction of patchless deopt, CR 6463133, so perhaps the changes
in that CR should be examined wrt diagnosing a root cause
for these crashes (or of unmasking a latent pre-existing bug).

In server mode the crash is very easy to reproduce, for example,
running javac from specjvm98 with the above options.

[NOTE: In client mode i have not been able to crash it in product mode.
However, in debug mode we easily get an assert even with -client; however,
the asserts in -client appear to be independent of, and long
predate the changes in CR 6463133, so these asserts in client
mode may be a red herring as far as the main problem here; nonetheless,
fixing these failing asserts would be nice.]
Vladimir believes this may be a duplicate of CR 6380402.

EVALUATION This is caused by this code in forte.cpp: #if defined(IA32) || defined(AMD64) // C2 on X86 can use the ebp register as a general purpose register // which can cause the candidate to fail theforte_safe_for_sender() // above. We try one more time using a NULL frame pointer (fp). candidate = frame(candidate.sp(), NULL, candidate.pc()); ... This builds a frame with an invalid unextended_sp which will screw up the stack walking.

13-09-2007

Duplicate :	JDK-6660253 - Core dump in AsyncGetCallTrace
Duplicate :	JDK-6380402 - JVM crash when runing the Collector with Java profiling on for xalan benchmark
Duplicate :	JDK-6575127 - ss12 analyzer crashes jvm 7 on specjvm.compiler tests on Clovertown
Relates :	JDK-6511756 - forte_is_valid_method() should call CollectedHeap::is_in_reserved() rather than is_in()
Relates :	JDK-6936709 - AsyncGetCallTrace doesn't handle inexact stack walking properly
Relates :	JDK-6463133 - Deoptimization should not use code patching