[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262669#comment-14262669
]
graham sanderson edited comment on CASSANDRA-8325 at 1/1/15 9:53 PM:
-
Since I'm feeling new-yearly I have made untested_8325.patch which seems (again
untested on anything least of all FreeBSD) like it should address the problems
Benedict you might want to take a quick look - this isn't going to win any
awards for prettiness or encapsulation, but it isn't immediately obvious that
it should make *anything* slower.
was (Author: graham sanderson):
Since I'm feeling new-yearly I have made untested_8325.patch which seems (again
untested on anything least of all FreeBSD) like it should address the problems
Benedict you might want to take a quick look - this isn't going to win any
awards for prettyness or encapsulation, but it isn't immediately obvious that
it should make *anything* slower.
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, unsafeCopy1.txt,
untested_8325.patch
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227227#comment-14227227
]
graham sanderson edited comment on CASSANDRA-8325 at 12/29/14 4:28 PM:
---
unsafeCopy1.txt has a minimal code change that *might* based on the
documentation for Unsafe.java fix this one code path (others would remain in
the comparators).
basically this is untested (even not on FreeBSD) so YMMV. Feel free to try it
and see if it fixes the exception in the copy() method
was (Author: graham sanderson):
unsafeCopy1.txt has a minimal code change that *might* based on the
documentation for Unsafe.java fix this one code path (others would remain in
the compators).
basically this is untested (even not on FreeBSD) so YMMV. Feel free to try it
and see if it fixes the exception in the copy() method
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, unsafeCopy1.txt
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227049#comment-14227049
]
graham sanderson edited comment on CASSANDRA-8325 at 11/27/14 12:30 AM:
Yeah the code in library_call.cpp is quite hard to introspect, however my sense
is this probably comes down to a mixture of the case where a null (0) 32 bit
compressedOop pointer is not equivalent to a null 64 bit address (i.e. the case
where the heap does not fit in the 32 gig of address space) possibly coupled
with whether the hotspot compiler could prove at compile time whether the value
was statically null.
It seems like a slightly strange distinction to make given that you are using a
64 bit offset anyway (and that other methods do using them interchangeably) but
that doesn't change the fact that they made the distinction and apparently it
matters at least in some implementations.
The question I was trying to get a sense of, is whether this explicitly
disallows the sorts of pointer arithmetic C* is trying to achieve, or whether
C* is just doing it wrong. Maybe that is actually quite simple and there are
clearly distinctions in the C* usage between baseless pointers and static or
otherwise field level offsets, but someone would have to have to dive in
(probably with the ability to test) to make sure.
was (Author: graham sanderson):
Yeah the code in library_call.cpp is quite hard to introspect, however my sense
is this probably comes down to a mixture of the case where a null (0) 32 bit
compressedOop pointer is not equivalent to a null 64 bit address (i.e. the case
where the heap does not fit in the 32 gig of address space) possibly coupled
with whether the hotspot compiler could prove at compile time whether the value
was statically null.
It seems like a slightly strange distinction to make given that you are using a
64 bit offset anyway (and that other methods do using them interchangeably) but
that doesn't change the fact that they made the distinction and apparently it
matters at least in some implementations.
The question I was trying to get a sense of, is whether this explicitly
disallows the sorts of pointer arithmetic C* is trying to achieve, or whether
C* is just doing it wrong. Maybe that is actually quite simple and there are
clearly distinctions between baseless pointers and static or otherwise field
level offsets, but someone would have to have to dive in (probably with the
ability to test) to make sure.
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227227#comment-14227227
]
graham sanderson edited comment on CASSANDRA-8325 at 11/27/14 3:52 AM:
---
unsafeCopy1.txt has a minimal code change that *might* based on the
documentation for Unsafe.java fix this one code path (others would remain in
the compators).
basically this is untested (even not on FreeBSD) so YMMV. Feel free to try it
and see if it fixes the exception in the copy() method
was (Author: graham sanderson):
unsafeCopy1.txt has a minimal code change that *might* based on the
documentation for Unsafe.java fix this one code path (others would remain in
the compators).
basically this is untested (even not on FreeBSD) so YMMV
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, unsafeCopy1.txt
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225120#comment-14225120
]
graham sanderson edited comment on CASSANDRA-8325 at 11/25/14 7:57 PM:
---
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this should be classed as a bug, maybe [~benedict] has some
ideas
was (Author: graham sanderson):
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this could be classed as a bug, maybe [~benedict] has some
ideas
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225120#comment-14225120
]
graham sanderson edited comment on CASSANDRA-8325 at 11/25/14 7:57 PM:
---
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this should be classed as a bug, maybe [~benedict] has some
ideas regarding the origin of this code
was (Author: graham sanderson):
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this should be classed as a bug, maybe [~benedict] has some
ideas
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225120#comment-14225120
]
graham sanderson edited comment on CASSANDRA-8325 at 11/25/14 7:57 PM:
---
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this could be classed as a bug, maybe [~benedict] has some
ideas
was (Author: graham sanderson):
True - it would seem that probably most of {{FastByteOperations}} may be making
invalid assumptions, and indeed appears to be new in 2.1 (I thought this might
be avoided by memtable_allocation_type: heap_buffers, but it isn't)
So yes... I guess this could be classed as a bug, maybe ~benedict has some ideas
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225151#comment-14225151
]
graham sanderson edited comment on CASSANDRA-8325 at 11/25/14 8:27 PM:
---
And finally, the C* code base seems to use the two interchangeably in some
cases which is might make it non trivial to disentangle (thus my suggested fix
above might just push the problem around in so far as the caller may have
incorrectly converted (obj, offset) to (null, address_of_obj + offset))
was (Author: graham sanderson):
And finally, the C* code base seems to use the two interchangeably in some
cases which is might make it non trivial to disentangle
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219824#comment-14219824
]
graham sanderson edited comment on CASSANDRA-8325 at 11/20/14 7:23 PM:
---
Just for sanity checking's sake - otherwise my previous comments about {{peer}}
still stand, can you check:
{code}
System.err.println(byteA + unsafe.getByte(null, l)); // that is your long l
System.err.println(byteB + unsafe.getByte(l)); // that is your long l
{code}
To make sure neither fail.
was (Author: graham sanderson):
Just for sanity checking's sake - otherwise my previous comments about {{peer}}
still stand, can you check:
{code}
System.err.println(byteA + theUnsafe.getByte(null, l)); // that is your long
l
System.err.println(byteB + theUnsafe.getByte(l)); // that is your long l
{code}
To make sure neither fail.
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219829#comment-14219829
]
graham sanderson edited comment on CASSANDRA-8325 at 11/20/14 10:16 PM:
You might also want to try putting them (without the println) in a long tight
loop to get them out of the interpreter
was (Author: graham sanderson):
You might also want to try putting them (without the println in a long tight
loop to get them out of the interpreter also)
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14218918#comment-14218918
]
graham sanderson edited comment on CASSANDRA-8325 at 11/20/14 2:55 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.
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
{bq}
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
{bq}
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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214543#comment-14214543
]
Leonid Shalupov edited comment on CASSANDRA-8325 at 11/17/14 11:09 AM:
---
STR:
1. Get FreeBSD 10.0, install openjdk via pkg install openjdk 7
2. Download and unpack apache-cassandra-2.1.2-bin.tar.gz
3. Run ./cassandra in apache-cassandra-2.1.2/bin
4. In couple of seconds Cassandra will crash
was (Author: shalupov):
STR:
1. Get FreeBSD 10.1, install openjdk via pkg install openjdk 7
2. Download and unpack apache-cassandra-2.1.2-bin.tar.gz
3. Run ./cassandra in apache-cassandra-2.1.2/bin
4. In couple of seconds Cassandra will crash
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)
