Bug 222146 - java/openjdk8: Running a program of infinite recursion dumps core
Summary: java/openjdk8: Running a program of infinite recursion dumps core
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-java mailing list
URL:
Keywords:
Depends on: 212150
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-08 14:02 UTC by Gabor Pali
Modified: 2017-10-26 20:58 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (java)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Pali freebsd_committer 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 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 2017-09-10 14:26:39 UTC
That is the same for me even with `-Xss8m`.