Zero crashing on ARM

[Severin Gehwolf]

Hi,

It appears that platform has a different format wrt to cgroups. What do
you get when run with os+container debug logging?

/home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java -Xlog:os+container=debug

Do you see "Incompatible str containing cgroup and memory" messages?
Contents of /proc/self/mountinfo and /proc/self/cgroup would be useful
to know too.

Thanks,
Severin

On Wed, 2017-11-29 at 09:18 +0100, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> During my tests, I noticed that Zero is crashing on ARM (Debian armel):
> 
> (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ gdb /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-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 "arm-linux-gnueabi".
> 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 /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java...(no debugging symbols found)...done.
> (gdb) r
> Starting program: /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
> [New Thread 0xb6682470 (LWP 16442)]
> 
> Thread 2 "java" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb6682470 (LWP 16442)]
> OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372
> 372             memory->set_subsystem_path(base);
> (gdb) bt
> #0  OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372
> #1  0xb6bee5dc in os::pd_init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4908
> #2  0xb67fdf7c in os::init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/os.hpp:152
> #3  Arguments::parse_vm_init_args (java_tool_options_args=java_tool_options_args at entry=0xb6681b64, java_options_args=java_options_args at entry=0xb6681b80,
>     cmd_line_args=cmd_line_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:2379
> #4  0xb67fe1d0 in Arguments::parse (initial_cmd_args=initial_cmd_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:4049
> #5  0xb6cc97d4 in Threads::create_vm (args=args at entry=0xb6681e40, canTryAgain=canTryAgain at entry=0xb6681dbf) at
> /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3974
> #6  0xb6a98a5c in JNI_CreateJavaVM_inner (args=0xb6681e40, penv=0xb6681e3c, vm=0xb6681e38) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:3917
> #7  JNI_CreateJavaVM (vm=0xb6681e38, penv=0xb6681e3c, args=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:4012
> #8  0xb6f605a4 in InitializeJVM (ifn=<synthetic pointer>, penv=0xb6681e34, pvm=0xb6681e30) at
> /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
> #9  JavaMain (_args=<optimized out>) at /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:411
> #10 0xb6f81338 in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0
> #11 0xb6ed10cc in ?? () from /lib/arm-linux-gnueabi/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> It also crashes on SuperH (Debian sh4) but I cannot provide a backtrace in this
> case due to limitations of QEMU and GDB on SuperH currently being incomplete. But
> I guess that fixing the issue on ARM will also fix the issue on SuperH.
> 
> I haven't done any debugging yet, but any input is welcome :).
> 
> Adrian
>