JDK-8032207 : C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • CPU: sparc
  • Submitted: 2014-01-17
  • Updated: 2017-08-10
  • Resolved: 2014-01-18
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 7 JDK 8 JDK 9 Other
7u60Fixed 8Fixed 9 b03Fixed hs25Fixed
Related Reports
Relates :  
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
SQE is ok to take the fix in 7u60.
14-02-2014

7u60-critical-request: The Solaris OpsCenter team has run into this problem. The fix is zero risk and we should fix this in 7u60.
14-02-2014

details on the issue with JDK 7
14-02-2014

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.
14-02-2014

Release team: Approved for fixing
21-01-2014

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/
21-01-2014