cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Issue Comment Deleted] (CASSANDRA-5737) CassandraDaemon - recent unsafe memory access operation in compiled Java code
Date Thu, 18 Dec 2014 04:26:13 GMT


Jonathan Ellis updated CASSANDRA-5737:
    Comment: was deleted

Please note Glyn Davies is no longer available at Omnifone Ltd. For Omnifone related inquires
please contact +44 208 6000 580


> CassandraDaemon - recent unsafe memory access operation in compiled Java code
> -----------------------------------------------------------------------------
>                 Key: CASSANDRA-5737
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.6
>         Environment: Amazon EC2, XLarge instance.
> Ubuntu 12.04.2 LTS
> Raid 0 disks, with ext4 
>            Reporter: Glyn Davies
> I'm using 1.2.6 on Ubuntu AWS m1.xlarge instances with the Datastax Community package
and have tried using Java versions jdk1.7.0_25  jre1.6.0_45
> Also testing with and without libjna-java (ie the JNA jar)
> However, something has triggered a bug in the CassandraDaemon:
> ERROR [COMMIT-LOG-ALLOCATOR] 2013-07-05 15:00:51,663 (line 192)
Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
> java.lang.InternalError: a fault occurred in a recent unsafe memory access operation
in compiled Java code
>         at org.apache.cassandra.db.commitlog.CommitLogSegment.<init>(
>         at org.apache.cassandra.db.commitlog.CommitLogSegment.freshSegment(
>         at org.apache.cassandra.db.commitlog.CommitLogAllocator.createFreshSegment(
>         at org.apache.cassandra.db.commitlog.CommitLogAllocator.access$500(
>         at org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(
>         at
>         at Source)
> This brought two nodes down out of a three node cluster – using QUORUM write with 3
> Restarting the node replays this error, so I have the system in a 'stable' unstable state
– which is probably a good place for trouble shooting.
> Presumably something a client wrote triggered this situation, and the other third node
was to be the final replication point – and is thus still up.
> Subsequently discovered that only a reboot will allow that node to come back up.
> Java Bug raised with Oracle after finding a Java dump text indicating a SIGBUS.
> At this point, I'm thinking that there is potentially a Linux kernel bug being triggered?

This message was sent by Atlassian JIRA

View raw message