JDK-8168628 : (fc) SIGBUS when extending file size to map it
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2016-10-21
  • Updated: 2019-05-13
  • Resolved: 2016-12-07
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 8 JDK 9
8u162Fixed 9 b149Fixed
Related Reports
Duplicate :  
JDK-8205989 - JVM crashes in v ~StubRoutines::jint_disjoint_arraycopy
Relates :  
JDK-8202116 - (fc) FileChannel.map should ensure mapped region is backed by disk space
Relates :  
JDK-8202261 - (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space
Relates :  
JDK-8171452 - (ch) linux io_util_md: Operation not supported exception after 8168628
Description
FULL PRODUCT VERSION :
[megha@convsn101 ~]$ java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)


FULL OS VERSION :
Linux convsn101 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f192c7ea352, pid=20921, tid=139738801043200
#
# JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# v  ~StubRoutines::jshort_disjoint_arraycopy
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007f144c004800):  JavaThread "SEG_FILE_WRITER_10134_1204" [_thread_in_Java, id=24629, stack(0x00007f177988f000,0x00007f1779990000)]

siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr: 0x00007f12bb41d000

Registers:
RAX=0x00000005db2fb6fa, RBX=0x0000000000006422, RCX=0x0000000000003211, RDX=0xfffffffffffff3a4
RSP=0x00007f177998e170, RBP=0x00007f177998e170, RSI=0x00007f12bb4232fa, RDI=0x00000005db2fb6f0
R8 =0x0000000000000000, R9 =0x0000000000000001, R10=0x00007f192c7eacc0, R11=0x00007f12bae38ae0
R12=0x0000000000000000, R13=0x00000000005e4402, R14=0x00000005db2f51f0, R15=0x00007f144c004800
RIP=0x00007f192c7ea352, EFLAGS=0x0000000000010292, CSGSFS=0x0000000000000033, ERR=0x0000000000000006
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f177998e170)
0x00007f177998e170:   00000007ba6cf4e8 00007f192d0aa4eb
0x00007f177998e180:   00000007b86bb570 00000007ba9c2200
0x00007f177998e190:   00000000f8028f2c 00000001c552ca20
0x00007f177998e1a0:   00000005c364dca8 0000000000006422
0x00007f177998e1b0:   00000007b86f5760 00000005c364ddf0
0x00007f177998e1c0:   00000000f8028f2c 00007f192e1a87f4
0x00007f177998e1d0:   0000000001872fb0 00000005c364dd30
0x00007f177998e1e0:   0000000006c3c112 00007f192ebd7424
0x00007f177998e1f0:   00000007b86ef2e8 0000000006c3c111
0x00007f177998e200:   00000005c3659bb8 00000005c3659bb8
0x00007f177998e210:   00000001f824bb85 0000000006c3c407
0x00007f177998e220:   00000005c364c1a0 00000005c364c148
0x00007f177998e230:   00000000f8028f2c 00007f192ecba374
0x00007f177998e240:   00000001c5763b18 00000005c3659b60
0x00007f177998e250:   00000005c3659b80 00007f177a9b83a8
0x00007f177998e260:   00000005c364dd30 00000005c364dd80
0x00007f177998e270:   00000005c364dd10 00000005c3659bb8
0x00007f177998e280:   0000000058089d4c 0000000000091c60
0x00007f177998e290:   00000000f8028f2c 00007f192f4ffe64
0x00007f177998e2a0:   00000007b86f5760 00000007b86ef2e8
0x00007f177998e2b0:   0000000000000007 00000001c75fe1b8
0x00007f177998e2c0:   0000000000000007 38ebfc3738ebfc25
0x00007f177998e2d0:   0000000638ebfc2a 00000001c75fe150
0x00007f177998e2e0:   00000001c47311b8 00007f1438ebfc25
0x00007f177998e2f0:   0000000627c1f890 00000007c4f8407a
0x00007f177998e300:   00007f17e032f568 0000000000000000
0x00007f177998e310:   00007f1941db4c53 00007f1940f0afc1
0x00007f177998e320:   00007f144c008b40 00007f144c004800
0x00007f177998e330:   0000000000000000 00007f144c004800
0x00007f177998e340:   00007f177998e360 00007f1940ecb81f
0x00007f177998e350:   00007f144c008b40 00007f144c004800
0x00007f177998e360:   00007f177998e390 00007f1940f153d0 

Instructions: (pc=0x00007f192c7ea352)
0x00007f192c7ea332:   48 33 c0 c9 c3 66 0f 1f 84 00 00 00 00 00 c5 fa
0x00007f192c7ea342:   6f 44 d7 c8 c5 fa 7f 44 d6 c8 c5 fa 6f 4c d7 d8
0x00007f192c7ea352:   c5 fa 7f 4c d6 d8 c5 fa 6f 54 d7 e8 c5 fa 7f 54
0x00007f192c7ea362:   d6 e8 c5 fa 6f 5c d7 f8 c5 fa 7f 5c d6 f8 48 83 

Register to memory mapping:

RAX=0x00000005db2fb6fa is an unknown value
RBX=0x0000000000006422 is an unknown value
RCX=0x0000000000003211 is an unknown value
RDX=0xfffffffffffff3a4 is an unknown value
RSP=0x00007f177998e170 is pointing into the stack for thread: 0x00007f144c004800
RBP=0x00007f177998e170 is pointing into the stack for thread: 0x00007f144c004800
RSI=0x00007f12bb4232fa is an unknown 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
After some time , it just crashed.
It happened on two servers around same time.

REPRODUCIBILITY :
This bug can be reproduced often.
Comments
This change has been backed out of JDK 11 as it break sparse files. The real issue is that Unsafe copyMemory isn't using memory guards. That issue is tracked as JDK-8191278.
22-05-2018
Hi Robbin, Thanks for checking it!
06-12-2016
Hi Brian, I saw your new patch. Edit: I read your patch in hurry. (I read if else) Looks fin, works fine, thanks !
05-12-2016
Robbin, you are correct: I was so fixated on the no-RAF case that I forgot to update the other C code. I'll fix that today.
02-12-2016
Brian, your patch seem to work fine for no RAF case. But you didn't include any changes for RAF case, so there we still SIGBUS.
02-12-2016
Robbin, if you would test the patch in the review thread that would be helpful - thanks!
02-12-2016
Review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2016-December/003997.html
02-12-2016
I was thinking along the same lines with respect to MT-safe. In my testing, applying the foregoing 'synchronized' patch on top of mine resulted in TestCopyNoRAF not producing a SIGBUS error over a number of runs. This is not definitive proof of course.
01-12-2016
Yes, you are correct. I also get SIGBUS on TestCopyNoRAF (but only in 1 of 6 runs or so). To me this issue seem to be that FileChannel.map() is not MT-safe. Between we get the size and choose to truncate another thread can already have truncate the file to larger value, hence we would yank the file under his map. This patch (on top of Brian's) seems to remove my SIGBUS: diff -r 34d00c41a6ba src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java --- a/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java Wed Nov 30 10:13:00 2016 +0100 +++ b/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java Wed Nov 30 13:18:41 2016 +0100 @@ -899,3 +899,3 @@ return null; - + synchronized(nd) { long filesize; @@ -919,2 +919,3 @@ } + } if (size == 0) { I don't know if FileChannel.map() suppose to be MT-safe, javadocs just mumbles about: "Whether changes made to the content or size of the underlying file, by this program or another, are propagated to the buffer is unspecified. " It doesn't even say that we increase the file size as necessary, should we even be doing truncate? Maybe just fail the map instead?
30-11-2016
I had also patched io_util_md.c but I did not include it in the prior comment. The complete patch is below. This fails the no-RAF case with a SIGBUS. --- a/src/java.base/unix/native/libjava/io_util_md.c +++ b/src/java.base/unix/native/libjava/io_util_md.c @@ -215,7 +215,16 @@ handleSetLength(FD fd, jlong length) { int result; +#if defined(__linux__) + struct stat64 sb; + if (fstat64(fd, &sb) != -1 && length < sb.st_blocks*512) { + RESTARTABLE(ftruncate64(fd, length), result); + } else { + RESTARTABLE(fallocate64(fd, 0, 0, length), result); + } +#else RESTARTABLE(ftruncate64(fd, length), result); +#endif return result; } --- a/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c +++ b/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c @@ -181,9 +181,24 @@ Java_sun_nio_ch_FileDispatcherImpl_truncate0(JNIEnv *env, jobject this, jobject fdo, jlong size) { +#if defined(__linux__) + jint fd = fdval(env, fdo); + struct stat64 fbuf; + + if (fstat64(fd, &fbuf) != -1 && size < fbuf.st_blocks*512) { + return handle(env, + ftruncate64(fd, size), + "Truncation failed"); + } else { + return handle(env, + fallocate64(fd, 0, 0, size), + "Allocation failed"); + } +#else return handle(env, ftruncate64(fdval(env, fdo), size), "Truncation failed"); +#endif }
29-11-2016
"ftruncates set st_size, so we can't check length against it." The intent was this: open STSize: 0 b , STBlocks*512: 0 ftruncate STSize: 65536 b , STBlocks*512: 0 fallocate STSize: 65536 b , STBlocks*512: 65536 (attached demo for this) AFAIU if st_blocks*512 is lower than st_size backing storage is not certain, hence SIGBUS if we run of out disk. Your patch above would SIGBUS depending on if you are testing no RAF or RAF case. I also have: diff -r 5a3a34170501 src/java.base/unix/native/libjava/io_util_md.c --- a/src/java.base/unix/native/libjava/io_util_md.c Mon Nov 07 16:14:18 2016 -0800 +++ b/src/java.base/unix/native/libjava/io_util_md.c Tue Nov 29 08:22:45 2016 +0100 @@ -213,2 +213,13 @@ +jlong +handleGetRealSize(FD fd) +{ + struct stat64 sb; + if (fstat64(fd, &sb) == 0) { + return sb.st_blocks*512; + } else { + return -1; + } +} + jint @@ -217,3 +228,15 @@ int result; - RESTARTABLE(ftruncate64(fd, length), result); + +#if defined(__linux__) + jlong currentLength = handleGetRealSize(fd); + if (currentLength != -1 && length < currentLength) { + RESTARTABLE(ftruncate64(fd, length), result); + } else { + RESTARTABLE(fallocate64(fd, 0, 0, length), result); + } +#else + RESTARTABLE(ftruncate64(fd, length), result); +#endif So we can only use truncate if we have previously done an falllocate (e.g. st_blocks is set) and we want to shrink the file. (above patch is incorrect we can't use st_block*512 and st_size interchangeably obviously)
29-11-2016
I am not sure what is intended by "ftruncates set st_size, so we can't check length against it." With the following change however I still get a SIGBUS: --- a/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c +++ b/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c @@ -181,9 +181,24 @@ Java_sun_nio_ch_FileDispatcherImpl_truncate0(JNIEnv *env, jobject this, jobject fdo, jlong size) { +#if defined(__linux__) + jint fd = fdval(env, fdo); + struct stat64 fbuf; + + if (fstat64(fd, &fbuf) != -1 && size < fbuf.st_blocks*512) { + return handle(env, + ftruncate64(fd, size), + "Truncation failed"); + } else { + return handle(env, + fallocate64(fd, 0, 0, size), + "Allocation failed"); + } +#else return handle(env, ftruncate64(fdval(env, fdo), size), "Truncation failed"); +#endif }
28-11-2016
ftruncates set st_size, so we can't check length against it. But st_blocks will still be zero until actual allocation (or if files have holes in it smaller than st_size) (also we need rounding size to next 512) I took your patch and changed compares against st_size to st_blocks*512 instead, both my test and original reprod test reports "No space left on device" and we don't get SIGBUS. (I did not verify that we actually execute ftruncate path, but we should in theory)
24-11-2016
With the patch included below I still see the SIGBUS error but I have yet to see it if ftruncate64() simply replaces fallocate64() on Linux in these two locations. I do not understand why this is happening. --- a/src/java.base/unix/native/libjava/io_util_md.c +++ b/src/java.base/unix/native/libjava/io_util_md.c @@ -215,7 +215,16 @@ handleSetLength(FD fd, jlong length) { int result; +#if defined(__linux__) + jlong currentLength = handleGetLength(fd); + if (currentLength != -1 && length < currentLength) { + RESTARTABLE(ftruncate64(fd, length), result); + } else { + RESTARTABLE(fallocate64(fd, 0, 0, length), result); + } +#else RESTARTABLE(ftruncate64(fd, length), result); +#endif return result; } --- a/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c +++ b/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c @@ -181,9 +181,24 @@ Java_sun_nio_ch_FileDispatcherImpl_truncate0(JNIEnv *env, jobject this, jobject fdo, jlong size) { +#if defined(__linux__) + jint fd = fdval(env, fdo); + struct stat64 fbuf; + + if (fstat64(fd, &fbuf) != -1 && size < fbuf.st_size) { + return handle(env, + ftruncate64(fd, size), + "Truncation failed"); + } else { + return handle(env, + fallocate64(fd, 0, 0, size), + "Allocation failed"); + } +#else return handle(env, ftruncate64(fdval(env, fdo), size), "Truncation failed"); +#endif }
23-11-2016
I don't think we can simply replace ftruncate() with fallocate(). Based on some testing on Ubuntu, fallocate() does not reduce the file size if a truncation is truly called for whereas ftruncate() does reduce the file size. It seems that something a little more specific is called for here, perhaps a check in the truncate() call to do ftruncate() if the size is smaller and fallocate() if it is larger.
18-11-2016
No RAF case: [pid 6559] open("/tmp/file1479366432345", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3 [pid 6559] close(3) [pid 6559] open("/tmp/file1479366432345", O_RDWR) = 3 [pid 6559] ftruncate(3, 2097152000) = 0 [pid 6559] mmap(NULL, 2097152000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fc2cb000000 [pid 6559] --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7fc2cb000000} --- So with additionaly: diff -r 2349f2839ff8 src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c --- a/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c Wed Nov 16 11:05:55 2016 +0100 +++ b/src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c Thu Nov 17 08:12:14 2016 +0100 @@ -184,3 +184,3 @@ return handle(env, - ftruncate64(fdval(env, fdo), size), + fallocate64(fdval(env, fdo), 0, 0, size), "Truncation failed"); This works on no raf case for me and after this I do not see any ftruncate in jdk. And as you say, this is Linux specific.
17-11-2016
The attached class TestFileCopyNoRAF removes the use of RandomAccessFile and reproduces the SIGBUS with both the fallocate() and MAP_POPULATE changes so the suggested fix is insufficient in the general case. Perhaps the fallocate() needs to be inside the map() method call stack, e.g., in Java_sun_nio_ch_FileChannelImpl_map0()? Also, fallocate(2) seems to be Linux-specific. Solaris has posix_fallocate(3C) but the situation on OS X and Windows looks more complicated. On OS X one may apparently use fcntl(2) on the file descriptor with the F_PREALLOCATE command. Windows would require further investigation. Firstly though one would need to decide whether to extend the change to the other platforms or leave it as Linux-only.
16-11-2016
FYI: I can not get any faults when I have a backing file. It was the gc guys who talked about this, so there might be some situation which I cannot produce. Manpages only talks about SIGBUS and backing file... Since fallocate solves the re-pro I think it's pretty safe to go with only fallocate.
16-11-2016
Thanks for the clarification.
15-11-2016
Hi, sorry, you wrote: "Could not reproduce the problem with i8168628.java (which parameter value was used?)" It takes MB as input and writes on /tmp/, so to reproduce same error as you got with TestCopyFile, your /tmp should have less free disk than what your input to i8168628 is. Use dd or whatever fill it up first. I'll try to create a test for the MAP_POPULATE (run-out-of physical memory for the map) issue, which would result in SIGBUS also.
15-11-2016
Robbin, I am unclear as to what you intend by your most recent comment. Thanks.
15-11-2016
You need to fill up your disk first, either running TestFileCopy first or i8168628 repeatedly.
15-11-2016
Running TestFileCopy as above with Robbin's patch applied results in an IOException "Error copying file with fileName: testBigFile_4.dat : No space left on device java.io.IOException: No space left on device" which is better than a SIGBUS.
15-11-2016
Could not reproduce the problem with i8168628.java (which parameter value was used?) but was able to reproduce the error on my Ubuntu 64-bit VM using TestFileCopy.java: $ java -Xms4g -Xmx4g TestFileCopy [thread 8627 also had an error]# # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0x7) at pc=0x00007fcc8119ad95, pid=8598, tid=8629 # # JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-11-14-111134.bpb.jdk9-dev) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-2016-11-14-111134.bpb.jdk9-dev, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # v ~StubRoutines::jlong_disjoint_arraycopy
15-11-2016
Alan could you assign this to someone who knows what the right approach to this is.
11-11-2016
Brian - can you look at this? The suggestions on this have side effects, particularly MAP_POPULATE and will require further analysis to see if anything should be changed.
11-11-2016
FYI dummy fix: diff -r 5a3a34170501 src/java.base/unix/native/libjava/io_util_md.c --- a/src/java.base/unix/native/libjava/io_util_md.c Mon Nov 07 16:14:18 2016 -0800 +++ b/src/java.base/unix/native/libjava/io_util_md.c Thu Nov 10 14:16:46 2016 +0100 @@ -218,1 +218,1 @@ - RESTARTABLE(ftruncate64(fd, length), result); + RESTARTABLE(fallocate64(fd, 0, 0, length), result); diff -r 5a3a34170501 src/java.base/unix/native/libnio/ch/FileChannelImpl.c --- a/src/java.base/unix/native/libnio/ch/FileChannelImpl.c Mon Nov 07 16:14:18 2016 -0800 +++ b/src/java.base/unix/native/libnio/ch/FileChannelImpl.c Thu Nov 10 14:16:46 2016 +0100 @@ -87,1 +87,1 @@ - flags = MAP_SHARED; + flags = MAP_SHARED | MAP_POPULATE; @@ -90,1 +90,1 @@ - flags = MAP_SHARED; + flags = MAP_SHARED | MAP_POPULATE; Which in my case gives: Exception in thread "main" java.io.IOException: No space left on device at java.io.RandomAccessFile.setLength(java.base/Native Method) at i8168628.main(i8168628.java:14)
10-11-2016
Added my simple re-pro(i8168628.java).
10-11-2016
We also need to do mmap with MAP_POPULATE to not risk running out of memory, hence SIGBUS. I don't see anyway to fix this without performance regression or API breakage. Since the user are using Unsafe, I'm actually 'fine' with current behavior. But we should have a way for the user todo fallocate easily and use MAP_POPULATE flag. Also the user might not know that MappedByteBuffer.put is an unsafe operation and javadocs don't seem to mention this. All input here is welcome!
10-11-2016
At least on my machine the problem is that RandomAccessFile.setLength does ftruncate, which does not allocate space (fallocate is what you want here). The mapped memory will run out of backing disk, hence SIGBUS. So a file that is memory mapped with READ_WRITE (MAP_SHARED) must have a e.g. "setLength(long newLength, bool allocate = true)" call before map can be created to avoid SIGBUS. Not sure what else to-do, suggestions? (strace from much simpler re-producer) ############################################################################################# [pid 15751] open("/tmp/file1478720472343", O_RDWR|O_CREAT, 0666) = 3 [pid 15751] fstat(3, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 [pid 15751] lseek(3, 0, SEEK_CUR) = 0 [pid 15751] ftruncate(3, 536870912) = 0 [pid 15751] lseek(3, 0, SEEK_SET) = 0 .... [pid 15751] fstat(3, {st_mode=S_IFREG|0664, st_size=536870912, ...}) = 0 [pid 15751] mmap(NULL, 536870912, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f90e4000000 .... [pid 15751] --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7f90e4000000} --- #############################################################################################
09-11-2016
This crash is not related to JDK-8140671 (which was Graal only). In fact, it's not even a compiler issue as I'm able to reproduce this with -Xint (see attached hs_err_pid71898.log): Stack: [0x00007f1f1416d000,0x00007f1f1426e000], sp=0x00007f1f1426c098, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x112cef5] j jdk.internal.misc.Unsafe.copyMemory0(Ljava/lang/Object;JLjava/lang/Object;JJ)V+0 java.base@9-ea j jdk.internal.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V+29 java.base@9-ea j java.nio.DirectByteBuffer.put([BII)Ljava/nio/ByteBuffer;+110 java.base@9-ea j TestFileCopy.lambda$writeTemplateData$3(Ljava/nio/MappedByteBuffer;[BLjava/lang/String;JI)V+15 The original crash occurred in StubRoutines::jshort_disjoint_arraycopy just because C2 compiled the Unsafe.copyMemory as a call to a copy stub. The file offsets in the test seem to be okay. Maybe it's a bug in the MappedByteBuffer implementation. Assigning to the runtime team for further investigation.
08-11-2016
Submitter could able to reproduce on both the places "v ~StubRoutines::jlong_disjoint_arraycopy" and "~StubRoutines::jshort_disjoint_arraycopy" # JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 compressed oops) # Problematic frame: # v ~StubRoutines::jlong_disjoint_arraycopy # # JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 compressed oops) # Problematic frame: # v ~StubRoutines::jshort_disjoint_arraycopy # # Core dump written. Default location: /home/megha/wildfly-9.0.0.Final/core or core.14450 But with given test case i could able to reproduce only on ~StubRoutines::jlong_disjoint_arraycopy
25-10-2016
The attached crash log is a crash in a different location: v ~StubRoutines::jlong_disjoint_arraycopy
25-10-2016
-sh-4.1$ /opt/java/jdk-9_ea-139/bin/javac TestFileCopy.java -sh-4.1$ /opt/java/jdk-9_ea-139/bin/java -Xms10g -Xmx10g TestFileCopy TargetFolder: /tmp Error in TestFileCopy.writeTemplateData empty record for fileName: testBigFile_17.dat, startPosition: 3208642560 : null Error in TestFileCopy.writeTemplateData empty record for fileName: testBigFile_6.dat, startPosition: 3208642560 : null # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0x7) at pc=0x00007f1ae3c89616, pid=5108, tid=5136 # # JRE version: Java(TM) SE Runtime Environment (9.0+139) (build 9-ea+139) # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+139, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # v ~StubRoutines::jlong_disjoint_arraycopy # # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" (or dumping to /home/fmatte/JI/9044720/core.5108) # # An error report file with more information is saved as: # /home/fmatte/JI/9044720/hs_err_pid5108.log [thread 5148 also had an error] Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled [thread 5141 also had an error] [thread 5149 also had an error] [thread 5146 also had an error] Phoning home... Using server: 10.161.186.18, port 4711 [thread 5145 also had an error] [thread 5147 also had an error] [thread 5144 also had an error] # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
25-10-2016
Reproducible test case received from submitter
25-10-2016
There is no complete crash logs, no stack trace to analyze. Requested submitter to share the crash logs and test case == Could you please provide the complete crash logs and steps to reproduce this issue? ==
24-10-2016