United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7130676 Tiered: assert(bci == 0 || 0<= bci && bci<code_size()) during stack trace construction
JDK-7130676 : Tiered: assert(bci == 0 || 0<= bci && bci

Details
Type:
Bug
Submit Date:
2012-01-17
Status:
Closed
Updated Date:
2012-03-24
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs23
Fixed Versions:
hs23 (b12)

Related Reports
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
Fastdebug VM crashes with the following assertion when trying to construct stack trace for an uncaught exception in Reference Handler thread:
#
#  Internal Error (/tmp/jprt/P1/085000.jcoomes/source/src/share/vm/oops/methodOop.cpp:508), pid=25769, tid=26
#  assert(bci == 0 || 0<= bci && bci<code_size()) failed: illegal bci
#

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a81f60ddab06
                                     
2012-01-23
EVALUATION

7130676: Tiered: assert(bci == 0 || 0<= bci && bci<code_size()) during stack trace construction
Reviewed-by: kvn, iveresov

This appears to be a long standing issue that was exposed by the
tiered code.  The bci -1 is used to represent a point in a method
before execution has actually started and is commonly used for the
stack at the monitor enter of a synchronized method
(SynchronizationEntryBCI).  The code which records stack traces for
exception only records a u2 so the -1 doesn't fit and it blindly gets
smeared to 65535.  If that value is used to look up line number then
it asserts because the value is out of range.  In product mode the
line number code would report the line number with the highest bci in
the line number table when it really should report the lowest.  The
fix is to smear -1 to 0.

In this particular case we're throwing an OOM while inside the counter
overflow on entry to a method.  The exception appears to propagate up
from compile_method, presumably from the resolve_string_constants and
load_signature_classes calls.  compile_method_base is also declared
TRAPS though it can't actually throw an exception.  I think the whole
path from CompilationPolicy::event to compile_method_base should be
cleaned up so that exceptions can't propagate.  Any exception thrown
in the path are side effects and not exception that should even be
propagated to the regular Java code.  I'll file a separate bug for
this.

Tested with failing test from report.
                                     
2012-01-23
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a81f60ddab06
                                     
2012-03-22



Hardware and Software, Engineered to Work Together