[
https://issues.apache.org/jira/browse/CASSANDRA-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055471#comment-16055471
]
Benjamin Lerer commented on CASSANDRA-11200:
--------------------------------------------
Since CASSANDRA-7039, direct {{ByteBuffers}} are used directly by LZ4. I had
some offline discussion with [~barnie] and we believe that if the OS can't read
an mmapped page the code might ends up blaming LZ4.
It seems that this type of segmentation fault is often caused by memory mapped
file issue.
The underlying problem might be a memory issue or a disk fault. If the problem
is due to a disk fault, you should not be able to copy the SSTable file.
Now, I think that we should improve the way the error is being reported to be
able to know straight a way that the issue has occured during decompression and
which SSTable caused the problem.
> CompactionExecutor thread error brings down JVM in 3.0.3
> --------------------------------------------------------
>
> Key: CASSANDRA-11200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11200
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: debian jesse latest release, updated Feb. 20th
> Reporter: Jason Kania
> Priority: Critical
>
> When launching Cassandra 3.0.3, with java version "1.8.0_74", Cassandra
> writes the following to the debug file before a segmentation fault occurs
> bringing down the JVM - the problem is repeatable.
> DEBUG [CompactionExecutor:1] 2016-02-20 18:26:16,892 CompactionTask.java:146
> - Compacting (56f677c0-d829-11e5-b23a-25dbd4d727f6)
> [/var/lib/cassandra/data/sensordb/periodicReading/ma-367-big-Data.db:level=0,
> /var/lib/cassandra/data/sensordb/periodicReading/ma-368-big-Data.db:level=0,
> /var/lib/cassandra/data/sensordb/periodicReading/ma-371-big-Data.db:level=0,
> /var/lib/cassandra/data/sensordb/periodicReading/ma-370-big-Data.db:level=0,
> /var/lib/cassandra/data/sensordb/periodicReading/ma-369-big-Data.db:level=0, ]
> The JVM error that occurs is the following:
> \#
> \# A fatal error has been detected by the Java Runtime Environment:
> \#
> \# SIGBUS (0x7) at pc=0x00007fa8a1052150, pid=12179, tid=140361951868672
> \#
> \# JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build
> 1.8.0_74-b02)
> \# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode
> linux-amd64 compressed oops)
> \# Problematic frame:
> \# v ~StubRoutines::jbyte_disjoint_arraycopy
> \#
> \# Core dump written. Default location: /tmp/core or core.12179
> \#
> \# 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 (0x00007fa89c56ac20): JavaThread "CompactionExecutor:1"
> daemon [_thread_in_Java, id=12323,
> stack(0x00007fa89043f000,0x00007fa890480000)]
> siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr:
> 0x00007fa838988002
> Even if all of the files associated with "ma-[NNN]*" are removed, the JVM
> dies with the same error after the next group of "ma-[NNN]*" are eventually
> written out and compacted.
> Though this may be strictly a JVM problem, I have seen the issue in Oracle
> JVM 8.0_65 and 8.0_74 and I raise it in case this problem is due to JNI usage
> of an external compression library or some direct memory usage.
> I have a core dump if that is helpful to anyone.
> Bug CASSANDRA-11201 may also be related although when the exception
> referenced in the bug occurs, the JVM remains alive.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
