cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8812) JVM Crashes on Windows x86
Date Wed, 18 Feb 2015 13:21:11 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Benedict updated CASSANDRA-8812:
--------------------------------
    Attachment: 8812.txt

I suspect this is the bug. It looks like if the amount of utilised CL space exceeds the limit,
we can close without ensuring all writes pending have finished or been synced IFF we are force
discarding the segments. 

Since we mark the segments as clean and discard the tail of the segment, the isUnused() property
returns true even if there are still writes modifying the segment or syncs pending. This would
be fine ordinarily, because recycle calls sync() which ensures any pending writes and sync
complete first, however if we're exceeding the allocated space, we skip this step and just
immediately close (and delete) the file. The simplest solution is to ensure that close() prevents
any future sync() from doing any work, and also ensures any pending writes to the file/buffer
complete before closing it.

> JVM Crashes on Windows x86
> --------------------------
>
>                 Key: CASSANDRA-8812
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8812
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31
>            Reporter: Amichai Rothman
>            Assignee: Joshua McKenzie
>         Attachments: 8812.txt, crashtest.tgz
>
>
> Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash due to EXCEPTION_ACCESS_VIOLATION.
This happens inconsistently. The attached test project can recreate the crash - sometimes
it works successfully, sometimes there's a Java exception in the log, and sometimes the hotspot
JVM crash shows up (regardless of whether the JUnit test results in success - you can ignore
that). Run it a bunch of times to see the various outcomes. It also contains a sample hotspot
error log.
> Note that both when the Java exception is thrown and when the JVM crashes, the stack
trace is almost the same - they both eventually occur when the PERIODIC-COMMIT-LOG-SYNCER
thread calls CommitLogSegment.sync and accesses the buffer (MappedByteBuffer): if it happens
to be in buffer.force(), then the Java exception is thrown, and if it's in one of the buffer.put()
calls before it, then the JVM crashes. This possibly exposes a JVM bug as well in this case.
So it basically looks like a race condition which results in the buffer sometimes being used
after it is no longer valid.
> I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, as well
as on a modern.ie virtualbox image of Windows 7 32-bit running the JDK, and it happens both
with JDK 7 and JDK 8. Also defining an explicit dependency on cassandra 2.1.2 (as opposed
to the cassandra-unit dependency on 2.1.0) doesn't make a difference. At some point in my
testing I've also seen a Java-level exception on Linux, but I can't recreate it at the moment
with this test project, so I can't guarantee it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message