United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6603919 Stackwalking crash on x86 -server with Sun Studio's collect -j on
JDK-6603919 : Stackwalking crash on x86 -server with Sun Studio's collect -j on

Details
Type:
Bug
Submit Date:
2007-09-12
Status:
Closed
Updated Date:
2013-11-25
Project Name:
JDK
Resolved Date:
2008-05-21
Component:
hotspot
OS:
linux_suse_sles_9,linux,generic
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:
hs13 (b01)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
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.
                                     
2007-09-13



Hardware and Software, Engineered to Work Together