[
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)
