Question

这是Core转储。当我们运行2节点cassandra集群时会发生。当环中只有1个节点时工作正常。这是Cassandra 1.1.3，之前我们在生产中运行1.0.7并且工作得很好。关于可能导致这种情况的任何想法？

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7e174780, pid=18537, tid=276
#
# JRE version: 6.0_27-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.2-b06 mixed mode solaris-sparc compressed oops)
# Problematic frame:
# V  [libjvm.so+0x974780]  Unsafe_GetLong+0x120
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x000000010450f000):  JavaThread "Thrift:3" daemon [_thread_in_vm, id=276, stack(0xffffffff66000000,0xffffffff66100000)]

siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), si_addr=0xfffffffe719cc082

Registers:
 G1=0xffffffff7e484788 G2=0xffffffff7e484790 G3=0x000000000007a788 G4=0x000000000007a790
 G5=0x000000000007a400 G6=0xfffffffe6000e000 G7=0xffffffff74d0c200 Y=0x0000000000000000
 O0=0x0000000000000000 O1=0x0000000000000000 O2=0x0000000000080350 O3=0x0000000000080000
 O4=0x0000000000000000 O5=0x0000000030000000 O6=0xffffffff660fc9b1 O7=0xfffffffe719cc070
 L0=0x0000000103b8f720 L1=0xffffffff7e4847a0 L2=0x0000000000000000 L3=0x0000000000000006
 L4=0x0000000010450f00 L5=0x0000000000001ffc L6=0xffffffff660ff860 L7=0xffffffff7e48a350
 I0=0x0000000000000000 I1=0x000000010450f000 I2=0x0000000104551180 I3=0x0000000000000012
 I4=0xffffffff7bd00000 I5=0xffffffff7e40a000 I6=0xffffffff660fca61 I7=0xffffffff77c0e1f4
 PC=0xffffffff7e174780 nPC=0xffffffff7e174784


Top of Stack: (sp=0xffffffff660fd1b0)
0xffffffff660fd1b0:   0000000103b8f720 ffffffff7e4847a0
0xffffffff660fd1c0:   0000000000000000 0000000000000006
0xffffffff660fd1d0:   0000000010450f00 0000000000001ffc
0xffffffff660fd1e0:   ffffffff660ff860 ffffffff7e48a350
0xffffffff660fd1f0:   0000000000000000 000000010450f000
0xffffffff660fd200:   0000000104551180 0000000000000012
0xffffffff660fd210:   ffffffff7bd00000 ffffffff7e40a000
0xffffffff660fd220:   ffffffff660fca61 ffffffff77c0e1f4
0xffffffff660fd230:   0000000104551200 000000010450f000
0xffffffff660fd240:   0000000104551248 0000000104551208
0xffffffff660fd250:   ffffffff77c04f90 00000002719cbed8
0xffffffff660fd260:   ffffffff660fd408 0000000000000000
0xffffffff660fd270:   ffffffff600d7c70 ffffffff660fd518
0xffffffff660fd280:   ffffffff660fd410 ffffffff77c0af6c
0xffffffff660fd290:   ffffffff660fd410 000000010450f000
0xffffffff660fd2a0:   00000000000005f9 ffffffff660fd518 

Instructions: (pc=0xffffffff7e174780)
0xffffffff7e174760:   9e 10 20 00 f4 5d a0 10 10 80 00 05 e0 5d a0 08
0xffffffff7e174770:   de 5e a0 00 e0 5d a0 08 f4 5d a0 10 e4 5e a0 00
0xffffffff7e174780:   f0 5b c0 1b 02 c4 80 05 aa 10 20 07 7f e0 ca 99
0xffffffff7e174790:   90 10 00 1a f4 5d a0 10 f4 74 20 08 f8 5d a0 18 

Register to memory mapping:

G1=0xffffffff7e484788: __1cHnmethodG__vtbl_+0x1aa8 in /opt/app/t3atl1m5/tibco/tibcojre64/1.6.0_27/lib/sparcv9/server/libjvm.so at 0xffffffff7d800000
G2=0xffffffff7e484790: __1cHnmethodG__vtbl_+0x1ab0 in /opt/app/t3atl1m5/tibco/tibcojre64/1.6.0_27/lib/sparcv9/server/libjvm.so at 0xffffffff7d800000
G3=0x000000000007a788 is an unknown value
G4=0x000000000007a790 is an unknown value
G5=0x000000000007a400 is an unknown value
G6=0xfffffffe6000e000 is an unknown value
G7=0xffffffff74d0c200 is an unknown value

O0=0x0000000000000000 is an unknown value
O1=0x0000000000000000 is an unknown value
O2=0x0000000000080350 is an unknown value
O3=0x0000000000080000 is an unknown value
O4=0x0000000000000000 is an unknown value
O5=0x0000000030000000 is an unknown value
O6=0xffffffff660fc9b1 is pointing into the stack for thread: 0x000000010450f000
O7=

Answer 1

我知道它是一个旧的但我在jdk 1.8.0上有类似的问题 5.10 Generic_15xxx sun4u sparc SUNW，Sun-Fire-V240。

在这种情况下，我使用cassandra-all 2.0.3依赖试图lz4比较这个问题在CASSANDRA-6628 中讨论过。阅读你需要使用cassandra的所有细节 - 所有更新的2.0.5和lz4 1.3.0（覆盖cassandra提供的所有2.0.5女巫仍然是1.2.0）。请参阅lz4 issue和pull request。

使用以下maven依赖项为我工作。

<dependency>
    <groupId>org.apache.cassandra</groupId>
    <artifactId>cassandra-all</artifactId>
    <version>2.0.16</version>
</dependency>
<dependency>
    <groupId>net.jpountz.lz4</groupId>
    <artifactId>lz4</artifactId>
    <version>1.3.0</version>
</dependency>

我的崩溃日志

  #
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7dd6f740, pid=15886, tid=0x000000000000000e
#
# JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode solaris-sparc compressed oops)
# Problematic frame:
# V  [libjvm.so+0xd6f740]  Unsafe_GetInt+0x174
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /*****/hs_err_pid15886.log
Compiled method (nm)   44848 1811     n 0       sun.misc.Unsafe::getInt (native)
 total in heap  [0xffffffff6bff6190,0xffffffff6bff6570] = 992
 relocation     [0xffffffff6bff62b8,0xffffffff6bff62d8] = 32
 main code      [0xffffffff6bff62e0,0xffffffff6bff6568] = 648
 metadata       [0xffffffff6bff6568,0xffffffff6bff6570] = 8
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

在Solaris上运行Cassandra 1.1.3时JVM崩溃。

1 个答案: