JDK-8079156 : 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u45,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-04-30
  • Updated: 2017-08-16
  • Resolved: 2015-07-14
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 9
9 b75Fixed
Related Reports
Relates :  
JDK-8131167 - Make CodeBuffer dynamically grow/shrink as needed without having to provide a guess of how much space we need in advance
Relates :  
JDK-8080157 - assert(allocates2(pc)) failed: not in CodeBuffer memory
Description
Linux-i586 Java(fastdebug) hit assertion when executed with following options on Linux-x64 platform: 
java -client -XX:StackShadowPages=32
java -client -XX:StackShadowPages=33
...
java -client -XX:StackShadowPages=49
java -client -XX:StackShadowPages=50

Valid interval for StackShadowPages is [1...50].

Here is output for Java 9 b62 debug build(hs_err_pid2695.log is attached): 
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/codeBuffer.hpp:176
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/HUDSON/workspace/9-2-build-linux-i586/jdk9/2592/hotspot/src/share/vm/asm/codeBuffer.hpp:176), pid=2695, tid=4130257728
#  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xf41c5a00 <= 0xf41c5e81 <= 0xf41c5e80
#
# JRE version:  (9.0-b62) (build )
# Java VM: Java HotSpot(TM) Client VM (1.9.0-ea-fastdebug-b62 mixed mode linux-x86 )
# Core dump written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c" (or dumping to /home/dmitry/bundles/jdk9/b61/i586/fastdebug/bin/core.2695)
#
...

Linux-i586 Java 8u45 version is also affected.
Comments
In my opinion the CodeBuffer is not as robust as it should be - requiring to provide a memory size is fragile (instructions on some architectures are variable sized) and it sounds like we had to manually adjust the sizes before, and it's very likely we'll have to do so in the future. One way to make this code robust is to let the CodeBuffer itself figure out how big buffers are needed.
14-07-2015
The issue here is that the stack banging code adds instructions to the CodeBuffer and ends up overflowing it because for each page of ShadowStackPage we generate movptr. Here is a very simple fix: # hg diff src/cpu/x86/vm/sharedRuntime_x86_32.cpp diff -r 2f8eba9d2f69 src/cpu/x86/vm/sharedRuntime_x86_32.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Thu Jun 25 13:23:36 2015 +0000 +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Fri Jul 10 15:33:51 2015 -0500 @@ -2456,7 +2456,13 @@ // allocate space for the code ResourceMark rm; // setup code generation tools - CodeBuffer buffer("deopt_blob", 1024, 1024); + int stack_banging_padding = 0; +#ifdef ASSERT + if (UseStackBanging) { + stack_banging_padding = 112; // obtained experimentally by running with -XX:StackShadowPages=50 + } +#endif + CodeBuffer buffer("deopt_blob", 1024+stack_banging_padding, 1024); MacroAssembler* masm = new MacroAssembler(&buffer); int frame_size_in_words; OopMap* map = NULL;
10-07-2015
Go it - the problem was that jdk9 (since jdk8?) no longer builds client flavor by default. Once I configured the jdk9 build asking for the "client" flavor, the locally built jdk9 exhibits the issue. From http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html I needed: ./configure --with-debug-level=fastdebug --with-jobs=8 --with-jvm-variants=client I am now free to proceed with debugging...
07-07-2015
JDK built using gcc 4.8.1 does not exhibit the problem. I will see if I can get the exact 4.8.2 version of gcc
06-07-2015
I used the exact same src code as in jdk9 b71, which is the built that fails, but on my local fastbuild the issue does not reproduce. So to recap: I can reproduce the issue on my Ubuntu 12.0.4 with the officially built jdk9 b71 binaries, but the same code built locally works fine. The difference must be either in the gcc version (I use gcc 4.6.3, but the official binaries were produced by gcc 4.8.2) or the flags that were used to build. Next, I will try gcc 4.8.2
02-07-2015
My local build of latest jdk9 (also fastdebug) doesn't exhibit the issue, so it's either gone in the latest or it's due to the way we built it. First I will try to get the exact same sources.
02-07-2015
1 < StackShadowPages - out of range 1 <= StackShadowPages <= 31 - works 32 <= StackShadowPages <= 50 - crash StackShadowPages > 50 - out of range
02-07-2015
Able to reproduce on Ubuntu 12.04 LTS 32bit
02-07-2015
I see from the log that Dmitry used "Ubuntu 12.04.5 LTS" to reproduce whereas I'm using 14.04 and can not reproduce. I will try Ubuntu 12.x next [http://releases.ubuntu.com/12.04/]
02-07-2015
Additional information: 1) Reproduced with all mode execution - Xint, Xcomp, Xmixed 2) Also reproduced on Windows platform for 32 bit Java-fastdebug. 3) I check b10 fastdebug build and bug also reproduced on this old build.
22-06-2015
Looks similair
18-05-2015
ILW HML = P2 I: High, Crashes L: Medium, W: Low, Don't set StackShadowPages to a high value
05-05-2015