当我运行这两行时，JVM崩溃了：
javafx.stage.FileChooser fileChooser = new FileChooser();
File targetFile = fileChooser.showSaveDialog( mainStage );
我在Ubuntu 16.10，OpenJDK 8 64bit：
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.10.2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
内核版本：
Linux Joshua-PC 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
我尝试了此处概述的解决方案但没有成功：https://stackoverflow.com/a/34612376/61248
以下是错误日志的顶部：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8573f34e40, pid=19801, tid=0x00007f850d733700
#
# JRE version: OpenJDK Runtime Environment (8.0_131-b11) (build 1.8.0_131-8u131-b11-0ubuntu1.16.10.2-b11)
# Java VM: OpenJDK 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpthread.so.0+0x9e40] pthread_mutex_lock+0x0
#
# 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
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007f856c325800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=19824, stack(0x00007f850d633000,0x00007f850d734000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000006e6f84
Registers:
RAX=0x00007f8573f34e40, RBX=0x00007f856c2e1730, RCX=0x000000000000014c, RDX=0x00007f850d72b8b0
RSP=0x00007f850d72b828, RBP=0x00007f850d72b890, RSI=0x00007f850d72b8a0, RDI=0x00000000006e6f74
R8 =0x00007f850d72b890, R9 =0x00007f856c2919fd, R10=0x00007f854dd43387, R11=0x0000000000000065
R12=0x00007f850d72b88c, R13=0x0000000000000000, R14=0x00007f85007b27c8, R15=0x00007f850d72ce20
RIP=0x00007f8573f34e40, EFLAGS=0x0000000000010202, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f850d72b828)
0x00007f850d72b828: 00007f854dcd8bda 00007f850d72b8a0
0x00007f850d72b838: 00007f850d72b8b0 00007f851358d510
0x00007f850d72b848: 00007f856c29c720 00007f8518f02cc1
0x00007f850d72b858: 7b2d1296d82fd300 00007f856c29c720
0x00007f850d72b868: 00007f8518f02cc1 00007f8518f04494
0x00007f850d72b878: 00007f854dcb4f56 0000000000000003
0x00007f850d72b888: 00007f850d72b930 00007f8500883400
0x00007f850d72b898: 0000000000004d70 0000014e0000014c
0x00007f850d72b8a8: 00007f8500000000 0000015700000156
0x00007f850d72b8b8: 00007f8500000000 0000000000000000
0x00007f850d72b8c8: 7b2d1296d82fd300 00007f8500882a50
0x00007f850d72b8d8: 00007f8500882a84 00007f856c29c720
0x00007f850d72b8e8: 00007f8518ebd79f 0000000000000000
0x00007f850d72b8f8: 00007f854c3e2078 00007f8500883400
0x00007f850d72b908: 7b2d1296d82fd300 00007f850d72b9ec
0x00007f850d72b918: 00007f8500883fa8 00007f850d72b980
0x00007f850d72b928: 00007f8500883fa8 0000000000000000
0x00007f850d72b938: 00007f85007b27c8 00007f850d72ce20
0x00007f850d72b948: 00007f8518ebfcc0 00007f8500883e80
0x00007f850d72b958: 00007f8518e91487 00007f85007b27c8
0x00007f850d72b968: 00007f850087d250 00007f850d72b9a0
0x00007f850d72b978: 00007f8518e4fd1f 00007f850d72ba00
0x00007f850d72b988: 00007f850d72b9f0 00007f850d72b9e0
0x00007f850d72b998: 00007f84c40127b0 00007f84c4012870
0x00007f850d72b9a8: 00007f854c3e3557 0000000000000000
0x00007f850d72b9b8: 0000000000000000 0000000100000001
0x00007f850d72b9c8: 0000000c0000000c 0000000000000000
0x00007f850d72b9d8: 7b2d1296d82fd300 00007f85007b2600
0x00007f850d72b9e8: 00007f850087d250 0000000000000006
0x00007f850d72b9f8: 00007f8518e52e93 0000000000000000
0x00007f850d72ba08: 000001cc0000000c 0000000000000001
0x00007f850d72ba18: 00000006d82fd300 000000004000000c
Instructions: (pc=0x00007f8573f34e40)
0x00007f8573f34e20: 89 0c 25 e0 02 00 00 64 48 c7 04 25 f0 02 00 00
0x00007f8573f34e30: 00 00 00 00 b8 82 00 00 00 e9 e0 f9 ff ff 66 90
0x00007f8573f34e40: 8b 57 10 89 d1 81 e1 7f 01 00 00 90 89 d0 83 e0
0x00007f8573f34e50: 7c 0f 85 99 00 00 00 48 83 ec 08 85 c9 49 89 f8
Register to memory mapping:
RAX=0x00007f8573f34e40: pthread_mutex_lock+0 in /lib/x86_64-linux-gnu/libpthread.so.0 at 0x00007f8573f2b000
RBX=0x00007f856c2e1730 is an unknown value
RCX=0x000000000000014c is an unknown value
RDX=0x00007f850d72b8b0 is pointing into the stack for thread: 0x00007f856c325800
RSP=0x00007f850d72b828 is pointing into the stack for thread: 0x00007f856c325800
RBP=0x00007f850d72b890 is pointing into the stack for thread: 0x00007f856c325800
RSI=0x00007f850d72b8a0 is pointing into the stack for thread: 0x00007f856c325800
RDI=0x00000000006e6f74 is an unknown value
R8 =0x00007f850d72b890 is pointing into the stack for thread: 0x00007f856c325800
R9 =0x00007f856c2919fd is an unknown value
R10=0x00007f854dd43387: <offset 0xb0387> in /usr/lib/x86_64-linux-gnu/libX11.so.6 at 0x00007f854dc93000
R11=0x0000000000000065 is an unknown value
R12=0x00007f850d72b88c is pointing into the stack for thread: 0x00007f856c325800
R13=0x0000000000000000 is an unknown value
R14=0x00007f85007b27c8 is an unknown value
R15=0x00007f850d72ce20 is pointing into the stack for thread: 0x00007f856c325800
Stack: [0x00007f850d633000,0x00007f850d734000], sp=0x00007f850d72b828, free space=994k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libpthread.so.0+0x9e40] pthread_mutex_lock+0x0
C 0x0000000000004d70
答案 0 :(得分：2)
这是由于对全局热键使用外部库JNativeHook引起的，尤其是这一行：
GlobalScreen.registerNativeHook();
和这一行：
GlobalScreen.addNativeKeyListener( globalHotkeyListener );
我不明白为什么会导致这个问题，但删除这两个调用可以解决问题。 我想我将不得不寻找一个不同的全球热键库。
我与图书馆开发人员交谈过。他回顾了崩溃事件并表示它不会直接在库中发生，他表示问题可能出在“xcb”和linux上。他建议使用该库的早期版本（v2.0.2而不是v2.1.0）并解决了该问题。
答案 1 :(得分：1)
这是否可以重现？
指令流如下所示：
0: 89 0c 25 e0 02 00 00 mov %ecx,0x2e0
7: 64 48 c7 04 25 f0 02 movq $0x0,%fs:0x2f0
e: 00 00 00 00 00 00
14: b8 82 00 00 00 mov $0x82,%eax
19: e9 e0 f9 ff ff jmpq 0xfffffffffffff9fe
1e: 66 90 xchg %ax,%ax
这是从libpthread中__pthread_mutex_lock_full函数的末尾开始的。第一条指令发生故障，因为它尝试写入未映射的绝对地址0x2e0。该指令是正确指令的尾部，它通过%fs寄存器覆盖写入TCB：
993a: 64 48 89 04 25 e0 02 mov %rax,%fs:0x2e0
9941: 00 00
这也不是一个简单的杂散函数指针调用，因为JVM报告错误指令处于pthread_mutex_lock+0，即函数的正确启动。所以看起来JVM /动态链接器的libpthread视图稍微偏离（实际上移动了32个字节）。
编辑由于这是完全可重现的，因此我不是文件重写libpthread.so.0，正如我原先怀疑的那样。很可能是某种内存损坏在函数指针中翻转了一下。如果-Xcheck:jni没有提供任何提示，则需要与GDB进行扩展调试会话以确定根本原因（在valgrind下运行JVM可能有太多误报）。