[
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 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);}}
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.
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)
