[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218918#comment-14218918
]
graham sanderson edited comment on CASSANDRA-8325 at 11/20/14 2:57 AM:
-----------------------------------------------------------------------
I don't have FreeBSD, but posting my comment from user thread
{quote}
Only thing I can see from looking at the exception, is that it looks like maybe
the “peer” value in the RefCountedMemory object is probably 0
Given that Unsafe.allocateMemory should not return 0 even on allocation failure
(it should throw OOM, though you should add a log statement to the Memory class
to check that) - I’d suggest logging to see if anyone is calling
SSTableReader.releaseSummary, which could set the peer to 0
{quote}
Note this particular use of sun.misc.Unsafe is new in 2.1, however I thought
there were others in 2.0. It is possible your JVM doesn't support {{public
native long Unsafe.allocateMemory(long l);}} and returns 0, though in that case
you pretty much just need to switch back to the on heap memtable allocator.
Also IMHO it'd seem a bit bizarre to support sun.misc.Unsafe, but silently not
implement the methods.
In any case, if you cannot recompile Cassandra for new logging, you can
certainly write a simple Jave program which calls {{public native long
allocateMemory(long l);}}
was (Author: graham sanderson):
I don't have FreeBSD, but posting my comment from user thread
{quote}
Only thing I can see from looking at the exception, is that it looks like maybe
the “peer” value in the RefCountedMemory object is probably 0
Given that Unsafe.allocateMemory should not return 0 even on allocation failure
(it should throw OOM, though you should add a log statement to the Memory class
to check that) - I’d suggest logging to see if anyone is calling
SSTableReader.releaseSummary, which could set the peer to 0
{quote}
Note this particular use of sun.misc.Unsafe is new in 2.1, however I thought
there were others in 2.0. It is possible your JVM doesn't support {{public
native long Unsafe.allocateMemory(long l);}} and returns 0, though in that case
you pretty much just need to switch back to the on heap memtable allocator.
Also IMHO it'd seem a bit bizarre to support sun.misc.Unsafe, but silently not
implement the methods.
In either case, if you cannot recompile Cassandra for new logging, you can
certainly write a simple Jave program which calls {{public native long
allocateMemory(long l);}}
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -----------------------------------------------------
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
> Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
