[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032650#comment-17032650
]
David Capwell commented on CASSANDRA-15556:
-------------------------------------------
bq. but I remember segfaulting was somehow related to passing expected length.
Maybe it's worth to check/try again.
[~ifesdjeen] attempted to try that out but it looks like every method requires
length and all all methods boil down to the following methods
{code}
/** Decompresses <code>src[srcOff:]</code> into
<code>dest[destOff:destOff+destLen]</code>
* and returns the number of bytes read from <code>src</code>.
* <code>destLen</code> must be exactly the size of the decompressed data.
*
* @param src the compressed data
* @param srcOff the start offset in src
* @param dest the destination buffer to store the decompressed data
* @param destOff the start offset in dest
* @param destLen the <b>exact</b> size of the original input
* @return the number of bytes read to restore the original input
*/
public abstract int decompress(byte[] src, int srcOff, byte[] dest, int
destOff, int destLen);
/** Decompresses <code>src[srcOff:]</code> into
<code>dest[destOff:destOff+destLen]</code>
* and returns the number of bytes read from <code>src</code>.
* <code>destLen</code> must be exactly the size of the decompressed data.
* The positions and limits of the {@link ByteBuffer}s remain unchanged.
*
* @param src the compressed data
* @param srcOff the start offset in src
* @param dest the destination buffer to store the decompressed data
* @param destOff the start offset in dest
* @param destLen the <b>exact</b> size of the original input
* @return the number of bytes read to restore the original input
*/
public abstract int decompress(ByteBuffer src, int srcOff, ByteBuffer dest,
int destOff, int destLen);
{code}
see
https://github.com/lz4/lz4-java/blob/master/src/java/net/jpountz/lz4/LZ4FastDecompressor.java#L46
Given this, there isn't any method I see which doesn't take the length, and its
actually required; so unable to test against what you recommended.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --------------------------------------------------------------
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
> Reporter: David Capwell
> Assignee: David Capwell
> Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x0000000110d46ad1, pid=86555, tid=0x0000000000001103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
