Out of memory error when parsing bytes

[frewsxcv]

extern crate flac;

use std::io::{self, Read, Cursor};
use flac::{ByteStream, Stream};

fn main() {
    let input = b"\x66\x4c\x61\x43\x04\x30\x30\x30\x00\x00\x00\x00\x30\x30\x30\x30";
    let s = Stream::<ByteStream>::from_buffer(input);
    if let Ok(mut stream) = s {
        let _ = stream.info();
        let _ = stream.metadata();
        let mut iter = stream.iter();
        while iter.next().is_some() {
        }
    }
}

coreyf@aflstagingmachine ~/afl-flac-staging-area> cargo run --verbose
       Fresh strsim v0.3.0
       Fresh libc v0.2.5
       Fresh regex-syntax v0.2.2
       Fresh nom v1.1.0
       Fresh rustc-serialize v0.3.16
       Fresh gcc v0.3.21
       Fresh memchr v0.1.7
       Fresh hound v1.1.0
       Fresh afl-coverage-plugin v0.0.1 (file:///home/coreyf/afl-flac-staging-area)
       Fresh aho-corasick v0.4.0
       Fresh regex v0.1.48
       Fresh afl-coverage v0.0.1 (file:///home/coreyf/afl-flac-staging-area)
       Fresh docopt v0.6.78
       Fresh flac v0.1.0
       Fresh afl-staging-area v0.1.0 (file:///home/coreyf/afl-flac-staging-area)
     Running `target/debug/afl-staging-area`
fatal runtime error: out of memory
Process didn't exit successfully: `target/debug/afl-staging-area` (signal: 4)

Found using afl.rs ✨

[sourrust]

I've tried this example with and without afl, on master and v0.1.0. Can't seem to reproduce the out of memory error.

edit: tried this with the latest nightly:

Jeremy@iSabel » flac|(v0.1.0)✚1…3
⇒  rustc --version
rustc 1.8.0-nightly (dea183aa8 2016-02-02)

can you try the example with the latest nightly just so I can see if crops up again.

[frewsxcv]

I can't reproduce it on my Macbook Pro, but on both of my Linux boxes, here's what I get:

(gdb) r
Starting program: /tmp/hi/target/debug/hi
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x00005555555b9450 in oom::h3ba825d7f90fa817pvb ()
(gdb) bt
#0  0x00005555555b9450 in oom::h3ba825d7f90fa817pvb ()
#1  0x00005555555943bc in flac::raw_vec::RawVec<T>::with_capacity (cap=808464432) at ../src/liballoc/raw_vec.rs:104
#2  0x0000555555594300 in flac::vec::Vec<T>::with_capacity (capacity=808464432) at ../src/libcollections/vec.rs:287
#3  0x0000555555593541 in flac::metadata::parser::vorbis_comment (i=...) at <nom macros>:4
#4  0x000055555558a505 in flac::metadata::parser::block_data (input=..., block_type=4 '\004', length=3158064)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/metadata/parser.rs:284
#5  0x0000555555564bb1 in flac::metadata::parser::metadata_parser (input=...) at <nom macros>:140
#6  0x000055555556423e in flac::utility::parser (input=..., is_start=0x7fffffffdfb7)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/utility/mod.rs:59
#7  0x000055555555c2e8 in fnfn (i=...) at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/utility/mod.rs:69
#8  0x000055555555bdc5 in hi::utility::types::ByteStream<'a>.StreamProducer::parse<closure,flac::metadata::types::Metadata> (self=0x7fffffffe0a0, f=...)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/utility/types.rs:54
#9  0x000055555555bad9 in hi::utility::many_metadata<flac::utility::types::ByteStream,closure> (stream=0x7fffffffe0a0, f=...)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/utility/mod.rs:69
#10 0x000055555555b845 in hi::stream::Stream<P>::from_stream_producer (producer=..., error_str=...)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/stream.rs:90
#11 0x000055555555b7b2 in hi::stream::Stream<P>::from_buffer (buffer=...)
    at /home/coreyf/.cargo/registry/src/cf-workers-proxy-9e9.pages.dev-88ac128001ac3a9a/flac-0.1.0/src/stream.rs:82
#12 0x000055555555b5ae in hi::main () at src/main.rs:8
#13 0x00005555555afd95 in sys_common::unwind::try::try_fn::h11901883998771707766 ()
#14 0x00005555555ad709 in __rust_try ()
#15 0x00005555555afa37 in rt::lang_start::hc150f651dd2af18b44x ()
#16 0x000055555556339a in main ()

[sourrust]

Alright, I believe I fixed or at least put two checks in to prevent the error from happening. It seems that this has more to do with the rust compiler on Linux since the number, 808464432, is valid with it being smaller than the max size of a usize. The compiler actually tries to allocate data but ended up returning null. There isn't much I can do about the out of memory error itself besides preventing it from happening.

Other issues that brought up:

• Abort on some large allocation requests, Panic on other rust-lang/rust#26951
• containers should provide some way to not panic on failed allocations rust-lang/rust#29802

Let me know if this fixes the issue.

[frewsxcv]

Sounds good, thanks!