https://www.dropbox.com/s/ubfjbfe0oowfvtl/svg.zip?dl=0 when compressed to brotli is https://www.dropbox.com/s/9ifkxzaxblfhz50/svg.zip.compressed?dl=0

and it fails to roundtrip with the following message

"data/svg.zip.compressed":
output length = 65703
res = Err(Error { repr: Custom(Custom { kind: InvalidData, error: StringError("More uncompressed bytes than expected in meta-block") }) })
===========

However the copy and insert lengths appear to be the same as with the google-provided decompressor https://www.dropbox.com/s/gc6rjqtca4mi4cx/svg.zip.cerrlog.txt?dl=0

brotli's log:

https://www.dropbox.com/s/vptya6rxmks5f97/svg.zip.errlog.txt?dl=0

Here's the tail end of the log from the brotli-rs binary

Insert And Copy Length = 137
(m_len, self.meta_block.count_output, insert_length, copy_length) = (87897, 87883, 1, 3)
btype = 0
[p1, p2] = RingBuffer { buf: [0, 0], pos: 0, cap: 2 }
Context Mode = 3
Lit = 0 0
Count output 87884
Count output 87887
Insert And Copy Length = 182
(m_len, self.meta_block.count_output, insert_length, copy_length) = (87897, 87887, 6, 8)
Fatal (m_len, a, b, c) = (87897, 87887, 87893, 87901)
output length = 65703
res = Err(Error { repr: Custom(Custom { kind: InvalidData, error: StringError("More uncompressed bytes than expected in meta-block") }) })
===========

OK ()

extern crate brotli;

use std::io::{self, Read};
use brotli::Decompressor;

fn main() {
    let mut input = vec![];
    let _ = Decompressor::new(&b"\x1b\x3f\xff\xff\xdb\x4f\xe2\x99\x80\x12".to_vec() as &[u8]).read_to_end(&mut input);
}

Crash discovered using afl.rs

https://crates.io/crates/brotli

Servo has ownership of this name right now, but we can grant you access if you want. You just need to log in to (and by doing so 'creating') your crates.io account.

Brotli expects the literal_buf to be prepopulated with uncompressed_data, if such data is encountered before something needing context bytes.

Currently the literal_buf is left to be 0,0 despite an uncompressed meta-block being encountered

I tried this on the bro binary from google and it fails to decompress with brotli-rs when compressed using -q 4 -w 16

https://www.dropbox.com/s/il9uhagaaawxl6i/bro?dl=0

https://www.dropbox.com/s/2lb4dzpjczbv8ll/bro.br?dl=0

but this is true for almost every binary I checked... in fact I just wrote a checker script that simply, in a loop, compresses with bro -q X -w Y where x = {1..11} and y = {16..22} That's how I found this glitch.

   Compiling brotli v0.3.19 (file:///Users/coreyf/Development/rust/brotli-rs)
src/lib.rs:686:18: 686:33 error: const indexing is an unstable feature
src/lib.rs:686              sum += 32 >> code_lengths[i];
                                         ^~~~~~~~~~~~~~~
src/lib.rs:686:18: 686:33 help: in Nightly builds, add `#![feature(const_indexing)]` to the crate attributes to enable
src/lib.rs:1512:10: 1512:60 error: const indexing is an unstable feature
src/lib.rs:1512                 1 << BROTLI_DICTIONARY_SIZE_BITS_BY_LENGTH[copy_length]
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/lib.rs:1512:10: 1512:60 help: in Nightly builds, add `#![feature(const_indexing)]` to the crate attributes to enable
src/lib.rs:1518:34: 1518:84 error: const indexing is an unstable feature
src/lib.rs:1518             let transform_id = word_id >> BROTLI_DICTIONARY_SIZE_BITS_BY_LENGTH[copy_length];
                                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/lib.rs:1518:34: 1518:84 help: in Nightly builds, add `#![feature(const_indexing)]` to the crate attributes to enable
error: aborting due to 3 previous errors
Could not compile `brotli`.

To learn more, run the command again with --verbose.

coreyf@frewbook-pro ~/D/r/brotli-rs (master) [101]> rustc -Vv
rustc 1.6.0-nightly (d49e36552 2015-12-05)
binary: rustc
commit-hash: d49e365528e026df6f56fe5eb001e81e2383fbf5
commit-date: 2015-12-05
host: x86_64-apple-darwin
release: 1.6.0-nightly

extern crate brotli;

use std::io::Read;
use brotli::Decompressor;

fn main() {
    let mut input = vec![];
    let _ = Decompressor::new(&b"\x51\xac\x00\x48\x2f\x73\x14\x01\x14\x00\x00\x01\x00\x14\x14\xff\x00\x02\x00\x00\x00\x00\x00\x64\x14\x24\x14\x14\x14\x14\x14\x80\x00\x00\x14\xff\xff\x00\x00\x14\x14\x14\x14\x14\x14\x80\x00\x80".to_vec() as &[u8]).read_to_end(&mut input);
}

Crash discovered using afl.rs

extern crate brotli;

use std::io::Read;
use brotli::Decompressor;

fn main() {
    let mut input = vec![];
    let _ = Decompressor::new(&b"\x15\x3f\x60\x00\x15\x3f\x60\x00\x27\xb0\xdb\xa8\x80\x25\x27\xb0\xdb\x40\x80\x12".to_vec() as &[u8]).read_to_end(&mut input);
}

coreyf@frewbook-pro /t/meow (master) [101]> cargo run
     Running `target/debug/meow`
thread '<main>' panicked at 'shift operation overflowed', /Users/coreyf/.cargo/git/checkouts/brotli-rs-33811c30552ad7ba/master/src/lib.rs:1162
Process didn't exit successfully: `target/debug/meow` (exit code: 101)

Crash discovered using afl.rs

extern crate brotli;

use std::io::Read;
use brotli::Decompressor;

fn main() {
    let mut input = vec![];
    let _ = Decompressor::new(&b"\x11\x3f\x00\x00\x24\xb0\xe2\x99\x80\x12".to_vec() as &[u8]).read_to_end(&mut input);
}

coreyf@frewbook-pro /t/meow (master) [101]> cargo run
     Running `target/debug/meow`
thread '<main>' panicked at 'index out of bounds: the len is 255 but the index is 391', ../src/libcollections/vec.rs:1110
Process didn't exit successfully: `target/debug/meow` (exit code: 101)

Crash discovered using afl.rs

This squelches the handful of compiler warnings which were being generated.

It also swaps some assert_eq! instances for assert!s, since these can result in very lengthy console messages of essentially binary data.

On Windows, Git is often set up to convert Unix line-endings to Windows line-endings automatically for text files. This auto-conversion caused should_decompress_asyoulik_txt to fail for me on Windows.

Adding the gitattributes file avoids the auto-conversion and allows the test to pass.

I've been timing the C implementation versus the rust implementation and I generally notice about a factor of 8-10x difference.

Do you know offhand any obvious performance tradeoffs that were made in the design of this version?

Do you have any ideas about various strategies we could employ to bring it within a factor of two, or ideally to the same speed as the C version especially for multi-megabyte files?

I noticed no inline assembly in the C version, so I'm hoping it is possible to bring the rust version to parity.

Have you done any profiling of the existing code or compared it with the C code?