b***@freebsd.org
2016-05-18 08:37:58 UTC
Andrew Smith <***@gmail.com> has reassigned Bugzilla Automation
<***@FreeBSD.org>'s request for maintainer-feedback to ***@FreeBSD.org:
Bug 209599: SIGSEGV in regression test suite on OpenJDK8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209599
--- Description ---
Whilst investigating a stability problem that occurs periodically if we attempt
to utilise OpenJDK 8 with Tomcat (resulting in various SIGSEGV and SIGBUS
errors), I decided to build everything afresh from current sources and perform
run the test suite.
System information on JDK build test machine.
10.3-RELEASE FreeBSD
***@testbuild1:~ # freebsd-version
10.3-RELEASE
portsnap sources fetched and installed on 16th May
***@testbuild1:~ # ls -l /var/db/portsnap/
total 4504
-rw-r--r-- 1 root wheel 2255587 May 16 09:59 INDEX
drwxr-xr-x 2 root wheel 2237952 May 16 09:59 files
-rw-r--r-- 1 root wheel 451 May 16 09:56 pub.ssl
-rw-r--r-- 1 root wheel 272 May 16 09:56 serverlist
-rw-r--r-- 1 root wheel 272 May 16 09:56 serverlist_full
-rw-r--r-- 1 root wheel 40 May 16 09:56 serverlist_tried
-rw-r--r-- 1 root wheel 681 May 16 09:59 tINDEX
-rw-r--r-- 1 root wheel 85 May 16 09:59 tag
***@testbuild1:~ #
Build process cycle run as follows..
# Selected all build configurations up front for the whole depdency set using
postmaster
# Every option with the exception of turning on TEST for OpenJDK8 was set to
default.
portmaster -n java/openjdk8
# Build actual port so that the build area was not cleaned (as is the case when
using postmaster).
cd /usr/ports/java/openjdk8
make clean install
2 of the tests fail when running the regression tests and error logs can be
collected as follows..
/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/te
stoutput/jdk_core/output.txt
and to locate the stashed error reports in the test hierarchy..
***@testbuild1:~ # cd
/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/te
stoutput/jdk_core
***@testbuild1:/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-s
erver-release/testoutput/jdk_core
# find . -name 'hs_*'
./JTwork/java/nio/MappedByteBuffer/Truncate/hs_err_pid57787.log
./JTwork/sun/misc/CopyMemory/hs_err_pid57712.log
The logs always show SIGSEGV errors from the same locations with the failure
signal being triggered during calles to sun.misc.Unsafe methods..
Stack: [0x00007fffde0e0000,0x00007fffde1e0000], sp=0x00007fffde1df080, free
space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x8d3ced] JVM_handle_bsd_signal+0x120c2d
j sun.misc.Unsafe.putByte(Ljava/lang/Object;JB)V+0
j CopyMemory.set(Lsun/misc/Unsafe;JIII)V+23
j CopyMemory.testSetRawMemory(Lsun/misc/Unsafe;)V+32
j CopyMemory.main([Ljava/lang/String;)V+9
Stack: [0x00007fffdf1f1000,0x00007fffdf2f1000], sp=0x00007fffdf2f0860, free
space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x8d8d0a] JVM_handle_bsd_signal+0x125c4a
j sun.misc.Unsafe.getByte(J)B+0
j java.nio.MappedByteBuffer.load()Ljava/nio/MappedByteBuffer;+85
j Truncate$2.call()Ljava/lang/Void;+4
Cores in this initial run are pretty useless and I am now rebuilding with
FASTDEBUG in the hope of getting enough symbolic information for them to be
particularly useful, however, one observation is that the MappedByteBuffer core
always results in the stack being unavailable...
***@testbuild1:/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-s
erver-release/testoutput/jdk_core
# gdb -c ./JTwork/java/nio/MappedByteBuffer/Truncate/java.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
Core was generated by `java'.
Program terminated with signal 6, Aborted.
#0 0x0000000800f2635a in ?? ()
(gdb) info stack
#0 0x0000000800f2635a in ?? ()
Cannot access memory at address 0x7fffdf2efc48
(gdb)
<***@FreeBSD.org>'s request for maintainer-feedback to ***@FreeBSD.org:
Bug 209599: SIGSEGV in regression test suite on OpenJDK8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209599
--- Description ---
Whilst investigating a stability problem that occurs periodically if we attempt
to utilise OpenJDK 8 with Tomcat (resulting in various SIGSEGV and SIGBUS
errors), I decided to build everything afresh from current sources and perform
run the test suite.
System information on JDK build test machine.
10.3-RELEASE FreeBSD
***@testbuild1:~ # freebsd-version
10.3-RELEASE
portsnap sources fetched and installed on 16th May
***@testbuild1:~ # ls -l /var/db/portsnap/
total 4504
-rw-r--r-- 1 root wheel 2255587 May 16 09:59 INDEX
drwxr-xr-x 2 root wheel 2237952 May 16 09:59 files
-rw-r--r-- 1 root wheel 451 May 16 09:56 pub.ssl
-rw-r--r-- 1 root wheel 272 May 16 09:56 serverlist
-rw-r--r-- 1 root wheel 272 May 16 09:56 serverlist_full
-rw-r--r-- 1 root wheel 40 May 16 09:56 serverlist_tried
-rw-r--r-- 1 root wheel 681 May 16 09:59 tINDEX
-rw-r--r-- 1 root wheel 85 May 16 09:59 tag
***@testbuild1:~ #
Build process cycle run as follows..
# Selected all build configurations up front for the whole depdency set using
postmaster
# Every option with the exception of turning on TEST for OpenJDK8 was set to
default.
portmaster -n java/openjdk8
# Build actual port so that the build area was not cleaned (as is the case when
using postmaster).
cd /usr/ports/java/openjdk8
make clean install
2 of the tests fail when running the regression tests and error logs can be
collected as follows..
/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/te
stoutput/jdk_core/output.txt
and to locate the stashed error reports in the test hierarchy..
***@testbuild1:~ # cd
/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/te
stoutput/jdk_core
***@testbuild1:/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-s
erver-release/testoutput/jdk_core
# find . -name 'hs_*'
./JTwork/java/nio/MappedByteBuffer/Truncate/hs_err_pid57787.log
./JTwork/sun/misc/CopyMemory/hs_err_pid57712.log
The logs always show SIGSEGV errors from the same locations with the failure
signal being triggered during calles to sun.misc.Unsafe methods..
Stack: [0x00007fffde0e0000,0x00007fffde1e0000], sp=0x00007fffde1df080, free
space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x8d3ced] JVM_handle_bsd_signal+0x120c2d
j sun.misc.Unsafe.putByte(Ljava/lang/Object;JB)V+0
j CopyMemory.set(Lsun/misc/Unsafe;JIII)V+23
j CopyMemory.testSetRawMemory(Lsun/misc/Unsafe;)V+32
j CopyMemory.main([Ljava/lang/String;)V+9
Stack: [0x00007fffdf1f1000,0x00007fffdf2f1000], sp=0x00007fffdf2f0860, free
space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x8d8d0a] JVM_handle_bsd_signal+0x125c4a
j sun.misc.Unsafe.getByte(J)B+0
j java.nio.MappedByteBuffer.load()Ljava/nio/MappedByteBuffer;+85
j Truncate$2.call()Ljava/lang/Void;+4
Cores in this initial run are pretty useless and I am now rebuilding with
FASTDEBUG in the hope of getting enough symbolic information for them to be
particularly useful, however, one observation is that the MappedByteBuffer core
always results in the stack being unavailable...
***@testbuild1:/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-s
erver-release/testoutput/jdk_core
# gdb -c ./JTwork/java/nio/MappedByteBuffer/Truncate/java.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
Core was generated by `java'.
Program terminated with signal 6, Aborted.
#0 0x0000000800f2635a in ?? ()
(gdb) info stack
#0 0x0000000800f2635a in ?? ()
Cannot access memory at address 0x7fffdf2efc48
(gdb)