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.
Hi! I've had problems with this as well. Setting a larger stack area helped me. See if adding -Xss8m helps.
That is the same for me even with `-Xss8m`.
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
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.