JDK-8192154 : JVM crashes inside some chroot environments on linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2017-11-29
  • Updated: 2017-12-15
  • Resolved: 2017-11-30
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 10
10 b36Fixed
Related Reports
Relates :  
JDK-8146115 - Improve docker container detection and resource configuration usage
Description
Both the Server and the Zero variant of the JVM crash when run inside a chroot environment as they are being used for building packages:

(sid-amd64-sbuild)root@trlin:/usr/src/hs# gdb /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java                                                                                                                             
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7fe1700 (LWP 35159)]

Thread 2 "java" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fe1700 (LWP 35159)]
OSContainer::init () at /usr/src/hs/src/hotspot/os/linux/osContainer_linux.cpp:374
374             cpuset->set_subsystem_path(base);
(gdb) bt
#0  OSContainer::init () at /usr/src/hs/src/hotspot/os/linux/osContainer_linux.cpp:374
#1  0x00007ffff6a3057a in os::pd_init_container_support () at /usr/src/hs/src/hotspot/os/linux/os_linux.cpp:4908
#2  0x00007ffff62fbd3d in os::init_container_support () at /usr/src/hs/src/hotspot/share/runtime/os.hpp:152
#3  Arguments::parse_vm_init_args (java_tool_options_args=java_tool_options_args@entry=0x7ffff7fe0a90, java_options_args=java_options_args@entry=0x7ffff7fe0ac0, cmd_line_args=cmd_line_args@entry=0x7ffff7fe0ef0)
    at /usr/src/hs/src/hotspot/share/runtime/arguments.cpp:2379
#4  0x00007ffff62fc034 in Arguments::parse (initial_cmd_args=initial_cmd_args@entry=0x7ffff7fe0ef0) at /usr/src/hs/src/hotspot/share/runtime/arguments.cpp:4049
#5  0x00007ffff6bc488d in Threads::create_vm (args=0x7ffff7fe0ef0, canTryAgain=canTryAgain@entry=0x7ffff7fe0e27) at /usr/src/hs/src/hotspot/share/runtime/thread.cpp:3974
#6  0x00007ffff675bd91 in JNI_CreateJavaVM_inner (args=<optimized out>, penv=0x7ffff7fe0ee8, vm=0x7ffff7fe0ee0) at /usr/src/hs/src/hotspot/share/prims/jni.cpp:3917
#7  JNI_CreateJavaVM (vm=0x7ffff7fe0ee0, penv=0x7ffff7fe0ee8, args=<optimized out>) at /usr/src/hs/src/hotspot/share/prims/jni.cpp:4012
#8  0x00007ffff7795e34 in InitializeJVM (ifn=<synthetic pointer>, penv=0x7ffff7fe0ee8, pvm=0x7ffff7fe0ee0) at /usr/src/hs/src/java.base/share/native/libjli/java.c:1478
#9  JavaMain (_args=<optimized out>) at /usr/src/hs/src/java.base/share/native/libjli/java.c:411
#10 0x00007ffff79a9517 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#11 0x00007ffff72d782f in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

This issue should be fixed as it prevents OpenJDK from being built inside a chroot environment which is the common practice on most Linux distributions.
Comments
I just installed cgroupfs-mount and re-entered the chroot but that didn't change anything. However, keep in mind, I'm not using Docker or anything fancy. Just the plain old chroot command with /dev, /proc and /sys as bind-mounts into the chroot. Either way, your patch fixes the problem for me on all tested targets and configurations.
30-11-2017
I'm wondering why cgroup mounts are not showing up for Adrian. Does the /proc/self/mountinfo file contain cgroup entries (on sh4) change if you install the cgroupfs-mount package in the chroot?
30-11-2017
It looks like Adrian is running an exploded image, not a modular JRE/JDK image.
30-11-2017
I have added noreg-hard label. IMO, it is hard to write a regression test for this condition, since the condition is only reproducible on specific system environments.
29-11-2017
Your diagnosis was spot on. Cleaning the build and building again with the patch fixed the issue: (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -XX:-UseContainerSupport -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) real 0m1.139s user 0m1.104s sys 0m0.028s (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) real 0m1.299s user 0m1.280s sys 0m0.016s (sid-amd64-sbuild)root@trlin:/usr/src/hs# It also makes sense given the fact that I tried debugging the issue after the build failed, i.e. was incomplete. Subsequent test runs were performed in this build directory without rebuilding, just trying different options. And I can confirm the patch works.
29-11-2017
Ok, will do. Will take a little longer though since I am going home now :-).
29-11-2017
Yes, wipe out your output directory, add the patch to the container file, re-build and see if your issues go away.
29-11-2017
The strace -f output shows that you do not have a modules file which means you have a corrupt build. This causes the java startup to search for and open 4847 individual class files resulting in the performance problem you are seeing.
29-11-2017
Shall I perform another clean build?
29-11-2017
On a recent build prior this bug (not including a fix for this bug): <mock-chroot> sh-4.4# ./openjdk10-dev-build/bin/java -Xlog:os+container=trace -version [0.001s][trace][os,container] OSContainer::init: Initializing Container Support [0.002s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.002s][trace][os,container] Memory Limit is: 9223372036854771712 [0.002s][trace][os,container] Memory Limit is: Unlimited [0.002s][trace][os,container] Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares [0.002s][trace][os,container] CPU Shares is: 1024 [0.002s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us [0.002s][trace][os,container] CPU Quota is: -1 [0.002s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us [0.002s][trace][os,container] CPU Period is: 100000 [0.002s][trace][os,container] OSContainer::active_processor_count: 8 [0.002s][trace][os,container] Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares [0.002s][trace][os,container] CPU Shares is: 1024 [0.002s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us [0.002s][trace][os,container] CPU Quota is: -1 [0.002s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us [0.002s][trace][os,container] CPU Period is: 100000 [0.002s][trace][os,container] OSContainer::active_processor_count: 8 [0.002s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.002s][trace][os,container] Memory Limit is: 9223372036854771712 [0.002s][trace][os,container] Memory Limit is: Unlimited [0.002s][debug][os,container] container memory unlimited, using host value [0.002s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes [0.002s][trace][os,container] Memory Limit is: 9223372036854771712 [0.002s][trace][os,container] Memory Limit is: Unlimited [0.002s][debug][os,container] container memory unlimited, using host value [0.004s][trace][os,container] Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares [0.004s][trace][os,container] CPU Shares is: 1024 [0.004s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us [0.004s][trace][os,container] CPU Quota is: -1 [0.004s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us [0.004s][trace][os,container] CPU Period is: 100000 [0.004s][trace][os,container] OSContainer::active_processor_count: 8 [0.027s][trace][os,container] Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares [0.027s][trace][os,container] CPU Shares is: 1024 [0.027s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us [0.027s][trace][os,container] CPU Quota is: -1 [0.027s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us [0.027s][trace][os,container] CPU Period is: 100000 [0.027s][trace][os,container] OSContainer::active_processor_count: 8 openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.sgehwolf.openjdk-hs) OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.sgehwolf.openjdk-hs, mixed mode) It's definitely related to how the mountinfo and cgroup files in /proc look.
29-11-2017
strace with "-f"
29-11-2017
John Paul, is this perf issue only occuring in your chroot environment? I just ran with and without the container support on a very recent build on Linux x64 and I don't see any performance difference. The strace you sent isn't following fork. Please attach an strace -f trace.
29-11-2017
I'm doubtful this is a general chroot issue. The simple test case on a fedora rawhide mock (which is a chroot underneath) I'm seeing: <mock-chroot> sh-4.4# gcc test_container.c <mock-chroot> sh-4.4# ./a.out /proc/self/mountinfo /proc/self/cgroup running init Setting cgroup subsystem: cpuset = new CgroupSubsystem(/, /sys/fs/cgroup/cpuset); Setting cgroup subsystem: cpu = new CgroupSubsystem(/, /sys/fs/cgroup/cpu,cpuacct); Setting cgroup subsystem: cpuacct = new CgroupSubsystem(/, /sys/fs/cgroup/cpu,cpuacct); setting memory: memory = new CgroupSubsystem(/, /sys/fs/cgroup/memory); cpuset->set_subsystem_path(/) cpu->set_subsystem_path(/) cpuacct->set_subsystem_path(/) memory->set_subsystem_path(/) So, cpu, memory etc. do get initialized there. Would likely not cause a SEGV in such a chroot. So it largely depends on what gets bind mounted into the chroot and how the files in /proc look like.
29-11-2017
Yes, that seems to be correct: root@trlin:~> cat /proc/cpuinfo |grep ^processor | wc -l 32 root@trlin:~> free -h total used free shared buff/cache available Mem: 31G 2.3G 4.0G 49M 25G 28G Swap: 7.8G 184M 7.6G root@trlin:~>
29-11-2017
Does the output match the amount of memory and processors in your system?
29-11-2017
Here's the output with -Xlog:os=trace: (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -XX:-UseContainerSupport -Xlog:os=trace -version [0.000s][trace][os] active_processor_count: using static path - configured processors: 32 [0.001s][trace][os] active_processor_count: sched_getaffinity processor count: 32 [0.001s][debug][os] Initial active processor count set to 32 [0.001s][trace][os] total system memory: 33681981440 [0.001s][info ][os] Use of CLOCK_MONOTONIC is supported [0.001s][info ][os] Use of pthread_condattr_setclock is supported [0.001s][info ][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC [0.001s][info ][os] HotSpot is running with glibc 2.25, NPTL 2.25 [0.001s][info ][os] SafePoint Polling address: 0x00007f6b759fc000 [0.017s][trace][os] active_processor_count: using static path - configured processors: 32 [0.017s][trace][os] active_processor_count: sched_getaffinity processor count: 32 openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) real 0m22.236s user 0m21.976s sys 0m0.232s (sid-amd64-sbuild)root@trlin:/usr/src/hs# Attaching the strace output as file.
29-11-2017
Turning off Container support should be reverting back to the behavior that existed prior to my change. Could you try -Xlog:os=trace instead? Also an strace of the startup might help me understand what's causing the slowdown.
29-11-2017
Here's the trace output: (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -XX:-UseContainerSupport -Xlog:container+os=trace -version [0.006s][trace][os,container] OSContainer::init: Initializing Container Support [0.006s][trace][os,container] Container Support not enabled openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) real 0m27.049s user 0m26.061s sys 0m0.735s (sid-amd64-sbuild)root@trlin:/usr/src/hs#
29-11-2017
The primary target for JDK-8146115 is docker+cgroups where all of the required subsystems are available. If memory has not been limited, the file /sys/fs/cgroup/memory/memory.limit_in_bytes will contain the Unlimited value (9223372036854771712). The same is true of the rest of the subsystems. I don't really require the cpuacct subsystems but in some systems I've tested, the cpuacct subsystem is merged with the cpu subsystem. If one of the subsystems is missing, the container support will be disabled as you are now seeing.
29-11-2017
Assigning back to Bob as he's the original author of the container support.
29-11-2017
> Please explain how you can have a performance issue when the VM crashes during start up. The performance issue came when enabling container support to avoid the crash. With your change, we are avoiding container support and hence there is no performance problem anymore. I don't know the code well enough to understand why container support reduces performance, but it definitely does make a difference. > If I accidently detect that we are running under cgroup but the subsystem files that I find cause an invalid selection of the amount of physical memory or cpus, I could see how that might cause an problem. Was this the case? I didn't have any cgroups limitations set, so I don't think there should be a mismatch regarding physical memory or CPUs. > If you have a VM that runs exhibiting this perf problem under the chroot environment, please send me the -Xlog:container+os=trace output. I'll check that.
29-11-2017
@Bob. Right. That was my initial attempt too: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8192154/webrev.01/ Question is whether or not all of them are required. How does a container's file system with cpu limits, but *no* memory limits look like? Similarly, how does it look for a memory limit but no cpu limit? For the problematic files in question the cgroup mountinfo does not seem to exist, but a cgroup file does.
29-11-2017
Please explain how you can have a performance issue when the VM crashes during start up. If I accidently detect that we are running under cgroup but the subsystem files that I find cause an invalid selection of the amount of physical memory or cpus, I could see how that might cause an problem. Was this the case? If you have a VM that runs exhibiting this perf problem under the chroot environment, please send me the -Xlog:container+os=trace output.
29-11-2017
Yes, that change fixes the segfault and the performance issue: (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.root.hs, mixed mode) real 0m0.246s user 0m0.683s sys 0m0.072s (sid-amd64-sbuild)root@trlin:/usr/src/hs#
29-11-2017
java -Xlog:os+container=trace, should provide some useful information to help isolate these types of issues.
29-11-2017
I don't know what your file system looks like under chroot but this fix should solve your immediate problem. --- a/src/hotspot/os/linux/osContainer_linux.cpp +++ b/src/hotspot/os/linux/osContainer_linux.cpp @@ -325,6 +325,11 @@ if (mntinfo != NULL) fclose(mntinfo); + if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) { + log_debug(os, container)("Required cgroup subsystems not found"); + return; + } + /* * Read /proc/self/cgroup and map host mount point to * local one via /proc/self/mountinfo content above @@ -385,11 +390,6 @@ if (cgroup != NULL) fclose(cgroup); - if (memory == NULL || cpuset == NULL || cpu == NULL) { - log_debug(os, container)("Required cgroup subsystems not found"); - return; - } - // We need to update the amount of physical memory now that // command line arguments have been processed. if ((mem_limit = memory_limit_in_bytes()) > 0) {
29-11-2017
If there is a permission issue it should just return and do nothing cgroup related. I don't think that's an issue. $ gcc test_container.c $ ./a.out mountinfo_root cgroup_root running init Can't open mountinfo_root, Permission denied $ ls -l mountinfo_root cgroup_root -r--r-----. 1 root root 361 Nov 29 14:46 cgroup_root -r--r-----. 1 root root 4855 Nov 29 14:43 mountinfo_root Same with files being missing: $ ./a.out not_there not_cgroup_there running init Can't open not_there, No such file or directory
29-11-2017
On amd64: (sid-amd64-sbuild)root@trlin:/# ./test_container /proc/self/mountinfo /proc/self/cgroup running init cpuset->set_subsystem_path(/) memory->set_subsystem_path(/user.slice/user-0.slice/session-c101.scope) cpu->set_subsystem_path(/user.slice/user-0.slice/session-c101.scope) cpuacct->set_subsystem_path(/user.slice/user-0.slice/session-c101.scope) Required cgroup subsystems not found (sid-amd64-sbuild)root@trlin:/# On sh4: (sid-sh4-sbuild)glaubitz@nofan:/local_scratch/glaubitz$ ./test_container /proc/self/mountinfo /proc/self/cgroup running init cpuset->set_subsystem_path(/) cpu->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) cpuacct->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) memory->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) Required cgroup subsystems not found (sid-sh4-sbuild)glaubitz@nofan:/local_scratch/glaubitz$ I cannot test on the ARM boxes, unfortunately, as I don't have access to the mountinfo/cgroup information on this machine.
29-11-2017
[~glaubitz] Could you try the test case in a chroot of yours and post the output, please?
29-11-2017
$ cat sh4_mountinfo sh4_cgroup 216 82 0:48 / /dev/shm rw,relatime shared:138 - tmpfs none rw 225 82 8:5 / /local_scratch rw,relatime shared:33 - ext4 /dev/sda5 rw,data=ordered 232 82 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:13 - proc proc rw 233 225 0:4 / /local_scratch/sid-sh4-sbuild/proc rw,nosuid,nodev,noexec,relatime shared:13 - proc proc rw 221 82 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw 222 225 0:18 / /local_scratch/sid-sh4-sbuild/sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw 256 82 0:6 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=8136004k,nr_inodes=2034001,mode=755 257 225 0:6 / /local_scratch/sid-sh4-sbuild/dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=8136004k,nr_inodes=2034001,mode=755 10:perf_event:/ 9:cpuset:/ 8:pids:/user.slice/user-0.slice/session-c102.scope 7:net_cls,net_prio:/ 6:cpu,cpuacct:/user.slice/user-0.slice/session-c102.scope 5:blkio:/user.slice/user-0.slice/session-c102.scope 4:devices:/user.slice/user-0.slice/session-c102.scope 3:memory:/user.slice/user-0.slice/session-c102.scope 2:freezer:/ 1:name=systemd:/user.slice/user-0.slice/session-c102.scope $ ./a.out sh4_mountinfo sh4_cgroup running init cpuset->set_subsystem_path(/) cpu->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) cpuacct->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) memory->set_subsystem_path(/user.slice/user-0.slice/session-c102.scope) Required cgroup subsystems not found So even though memory is never initialized it attempts to use it. Hence the SEGV.
29-11-2017
Simple C test case derived from hotspot code. Run as: $ gcc test_container.c $ ./a.out <path-to-mountinfo-file> <path-to-cgroup>
29-11-2017
There is also a huge performance impact on Zero though. Not sure whether this is related to the container stuff though: (sid-sh4-sbuild)glaubitz@nofan:/local_scratch/glaubitz/openjdk/hs$ time /usr/bin/java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) real 0m0.572s user 0m0.572s sys 0m0.004s (sid-sh4-sbuild)glaubitz@nofan:/local_scratch/glaubitz/openjdk/hs$ time /local_scratch/glaubitz/openjdk/hs/build/linux-sh-normal-zero-release/jdk/bin/java -XX:-UseContain> qemu: Unsupported syscall: 318 Unsupported setsockopt level=1 optname=15 openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.glaubitz.hs) OpenJDK Zero VM (build 10-internal+0-adhoc.glaubitz.hs, interpreted mode) real 1m49.166s user 1m49.019s sys 0m0.152s (sid-sh4-sbuild)glaubitz@nofan:/local_scratch/glaubitz/openjdk/hs$ Some performance impact on the Server variant as well: (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/bin/java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode) real 0m0.101s user 0m0.112s sys 0m0.032s (sid-amd64-sbuild)root@trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:-UseContainerSupport -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.root.hs, mixed mode) real 0m1.080s user 0m3.622s sys 0m0.591s (sid-amd64-sbuild)root@trlin:/usr/src/hs#
29-11-2017
Yes, that fixes the problem! (sid-amd64-sbuild)root@trlin:/usr/src/hs# /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java -version Segmentation fault (sid-amd64-sbuild)root@trlin:/usr/src/hs# /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:-UseContainerSupport -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.root.hs, mixed mode) (sid-amd64-sbuild)root@trlin:/usr/src/hs#
29-11-2017
Does `-XX:-UseContainerSupport` make any difference?
29-11-2017