Bug 222146

Summary: java/openjdk8: Running a program of infinite recursion dumps core
Product: Ports & Packages Reporter: Gabor Pali <pgj>
Component: Individual Port(s)Assignee: freebsd-java (Nobody) <java>
Status: Closed FIXED    
Severity: Affects Many People CC: ari, emaste, girgen, glewis
Priority: --- Flags: bugzilla: maintainer-feedback? (java)
Version: Latest   
Hardware: Any   
OS: Any   

Description Gabor Pali freebsd_committer freebsd_triage 2017-09-08 14:02:54 UTC
The Java Runtime Environment shipped with the recent version of the `java/openjdk8` port crashes on an application that gets into an infinite recursion at execution.

Consider an example of that, `Foo.java`:

~~~~
public class Foo {
    public static void main(String[] args) {
        main(args);
    }
}
~~~~

that does the following:

~~~~
$ freebsd-version
11.1-RELEASE-p1
$ java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
$ javac Foo.java
$ java Foo
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000080394da40, pid=13843, tid=0x00000000000187c1
#
# JRE version: OpenJDK Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01)
# Java VM: OpenJDK 64-Bit Server VM (25.144-b01 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# J 12 C1 Foo.main([Ljava/lang/String;)V (5 bytes) @ 0x000000080394da40 [0x000000080394da40+0x0]
#
# Core dump written. Default location: /tmp/java.core
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid13843.log
Compiled method (c1)     301   12       3       Foo::main (5 bytes)
 total in heap  [0x000000080394d8d0,0x000000080394dca0] = 976
 relocation     [0x000000080394d9f8,0x000000080394da38] = 64
 main code      [0x000000080394da40,0x000000080394db60] = 288
 stub code      [0x000000080394db60,0x000000080394dc08] = 168
 oops           [0x000000080394dc08,0x000000080394dc10] = 8
 metadata       [0x000000080394dc10,0x000000080394dc18] = 8
 scopes data    [0x000000080394dc18,0x000000080394dc48] = 48
 scopes pcs     [0x000000080394dc48,0x000000080394dc98] = 80
 dependencies   [0x000000080394dc98,0x000000080394dca0] = 8
Compiled method (c1)     302   12       3       Foo::main (5 bytes)
 total in heap  [0x000000080394d8d0,0x000000080394dca0] = 976
 relocation     [0x000000080394d9f8,0x000000080394da38] = 64
 main code      [0x000000080394da40,0x000000080394db60] = 288
 stub code      [0x000000080394db60,0x000000080394dc08] = 168
 oops           [0x000000080394dc08,0x000000080394dc10] = 8
 metadata       [0x000000080394dc10,0x000000080394dc18] = 8
 scopes data    [0x000000080394dc18,0x000000080394dc48] = 48
 scopes pcs     [0x000000080394dc48,0x000000080394dc98] = 80
 dependencies   [0x000000080394dc98,0x000000080394dca0] = 8
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Abort (core dumped)
~~~~

Note that a slightly earlier version would not crash but print the resulting exception with an endless stack trace, something along this way:

~~~~
$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
$ java Foo
Exception in thread "main" java.lang.StackOverflowError
        at Foo.main(Foo.java:3)
        at Foo.main(Foo.java:3)
        at Foo.main(Foo.java:3)
[...]
~~~~

Although the program is bad, the VM should not crash still.  This is reproducible on different machines, I guess it must be a regression.
Comment 1 Palle Girgensohn freebsd_committer freebsd_triage 2017-09-09 12:46:24 UTC
Hi!

I've had problems with this as well. Setting a larger stack area helped me. See if adding 

-Xss8m

helps.
Comment 2 Gabor Pali freebsd_committer freebsd_triage 2017-09-10 14:26:39 UTC
That is the same for me even with `-Xss8m`.
Comment 3 commit-hook freebsd_committer freebsd_triage 2019-08-12 04:06:07 UTC
A commit references this bug:

Author: glewis
Date: Mon Aug 12 04:05:58 UTC 2019
New revision: 508703
URL: https://svnweb.freebsd.org/changeset/ports/508703

Log:
  Workaround for infinite recursion crash

  * FreeBSD crashes on infinite recursion rather than throwing a stack
    overflow because the stack address of the fault is in the page below
    the guard area.  Workaround this by rounding down the fault address to
    the nearest page boundary.  Investigation is still under way into what
    may be causing this but this appears to prevent it in simple test cases.

  PR:		222146

Changes:
  head/java/openjdk8/Makefile
  head/java/openjdk8/files/patch-hotspot_src_os__cpu_bsd__x86_vm_os__bsd__x86.cpp
Comment 4 Greg Lewis freebsd_committer freebsd_triage 2019-10-24 23:26:29 UTC
This is as fixed as it can get from the Java perspective.  It will work correctly on 11.3(?), 12.1 and later and on earlier releases if you set  security.bsd.stack_guard_page to be zero with sysctl.  If you don't set it to zero on earlier releases then it will still mostly work.