cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8812) JVM Crashes on Windows x86
Date Fri, 15 May 2015 16:53:01 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545777#comment-14545777
] 

Aleksey Yeschenko commented on CASSANDRA-8812:
----------------------------------------------

I'm assuming that this was reopened by accident. Either way, since the patch made it into
2.1.5, if the issue is still real, a new ticket should be opened instead of reopening one.

> 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: Benedict
>             Fix For: 2.1.5
>
>         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