United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8032207 : C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size

Details
Type:
Bug
Submit Date:
2014-01-17
Status:
Resolved
Updated Date:
2014-09-04
Project Name:
JDK
Resolved Date:
2014-01-18
Component:
hotspot
OS:
Sub-Component:
compiler
CPU:
sparc
Priority:
P1
Resolution:
Fixed
Affected Versions:
hs25
Fixed Versions:

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

Sub Tasks

Description
While trying to exercise the loadI2L_immI rule on sparc, I hit the following fastdebug crash:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/ad_sparc.cpp:7967
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (../generated/adfiles/ad_sparc.cpp:7967), pid=7960, tid=31
#  assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b123) (build 1.8.0-ea-fastdebug-b123)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b65-fastdebug mixed mode solaris-sparc compressed oops)

With a product build, the crash is less informative:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (output.cpp:1559), pid=7968, tid=31
#  guarantee((int)(blk_starts[i+1] - blk_starts[i]) >= (current_offset - blk_offset)) failed: shouldn't increase block size
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b123) (build 1.8.0-ea-b123)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b65 mixed mode solaris-sparc compressed oops)

% cat a1.java
public class a1 {
    static int x[] = new int[1];
    static long foo() {
        return x[0] & 0xfff0ffff;
    }

    public static void main(String[] args) {
        x[0] = -1;
        long l = 0;
        for (int i = 0; i < 100000; ++i) {
            l = foo();
        }
        System.out.println(l);
    }
}

To reproduce:
% java -server -XX:-TieredCompilation a1

                                    

Comments
ILW=HHH=P1

Impact:  Crash, the test case is very simple.
Likelihood:  This reproduces all the time.
Workaround: None

Justification:   This affects any code that does a bitwise AND with a integer loaded from memory and constant mask value with conversion to a long. The JVM crashes because the code created for this sequence of operations was specified to have a fix size, which is incorrect in this case because the operation of loading of an unknown constant to a register is variable sized and depends on the actual constant. If not caught early like it is in the debug version, this could lead to problems in computing correct branch offsets and, as a result, to arbitrary behavior.

Risk:  Zero, the change causes the JVM to calculate the size of the emitted instructions rather then using the precomputed size. 

This change has already been committed to JDK 9 repo but should be pushed to JDK 8 as well.

Diff:  http://cr.openjdk.java.net/~iveresov/8032207/webrev.01/
                                     
2014-01-17
URL:   http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9918c6fb4770
User:  iveresov
Date:  2014-01-18 03:25:31 +0000

                                     
2014-01-18
Release team: Approved for fixing
                                     
2014-01-21
URL:   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9918c6fb4770
User:  lana
Date:  2014-02-11 20:38:10 +0000

                                     
2014-02-11
Looks like this issue is reproducible with latest S11.1 SRU15 that embeds JDK 7. Copying email discussion on that topic here:

.....
On 13/02/2014 21:07, Igor Veresov wrote:
> Hi Serge,
>
> Yes, it could very well be that issue.
>
> igor
>
> On Feb 13, 2014, at 7:49 AM, Serge Dussud wrote:
>
>>
>> Hi Igor,
>>
>> I see that you've worked on the below JDK bug:
>> https://bugs.openjdk.java.net/browse/JDK-8032207
>>
>> and I am wondering if I am hitting same issue with jdk 7. The context is that I am testing OpsCenter softwarevand Solaris 11.1 SRU15, and I am hitting issue because of the below java crash (see also attachment for more java data on the issue).
>>
>> Does that shed some light ? any comment or advice would be much appreciated,
>> TIA !
>>
>> Serge
>>
>>
>>
>> -------- Original Message --------
>> Subject: 	Re: s11.1SRU15 weirdness ? Re: LDOM T4-1 S11 API - Nightly Run on sm4170m2-52-n172: FAIL
>> Date: 	Thu, 13 Feb 2014 16:27:52 +0100
[..]
>>
>>
>>
>> An update on this: re-running the job went a bit better but jobs now fail in Verify Agent Install task, failing to configure agent. Looks like a jvm crash. Any comments/ideas anyone ?
>>
>> ...
>> executing step : sc_console
>> verified sc_console command is OK
>> Configuring sc_console
>> checking existing sc_console connections
>> doing sc-console registration
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (output.cpp:1576), pid=3601, tid=15
>> #  guarantee((int)(blk_starts[i+1] - blk_starts[i]) >= (current_offset - blk_offset)) failed: shouldn't increase block size
>> #
>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
>> # Java VM: Java HotSpot(TM) Server VM (24.51-b03 mixed mode solaris-sparc )
>> # Core dump written. Default location: /opt/SUNWxvmoc/private/steps/core or core.3601
>> #
>> # An error report file with more information is saved as:
>> # /opt/SUNWxvmoc/private/steps/hs_err_pid3601.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.sun.com/bugreport/crash.jsp
>> #
>> Agent Configuration failed:1
>> /usr/sfw/bin/wget -O /tmp/S99agent_ret_status.run -t 5 -T 5 http://10.166.172.134:8004/scnospstat/?phase=agent&client_id=10.166.174.158\&job_id=sm4170m2-52-n172.165&status=configerror&conn_id=found.
>> /bin/rm -rf /var/tmp/OpsCenterAgent
>> root@smvt-174-158:/var/tmp#


Attaching hs_err_pid3601.log.

                                     
2014-02-14
details on the issue with JDK 7
                                     
2014-02-14
7u60-critical-request:  The Solaris OpsCenter team has run into this problem.  The fix is zero risk and we should fix this in 7u60.
                                     
2014-02-14
SQE is ok to take the fix in 7u60.
                                     
2014-02-14



Hardware and Software, Engineered to Work Together