json-rust-0.11.3 fails its test suite in 1.15 beta with SIGSEGV

[brson]

Regression from 1.14.

https://github.com/maciejhirsz/json-rust commit 3bc4e49687bfaa541214d4a3371a543231e18069

brian@ip-10-145-43-250:/mnt2/dev/json-rust⟫ rustc +beta -Vv
rustc 1.15.0-beta.1 (d9a0f0df7 2016-12-19)
binary: rustc
commit-hash: d9a0f0df7051c603011d6b60fbdd155318fc47f3
commit-date: 2016-12-19
host: x86_64-unknown-linux-gnu
release: 1.15.0-beta.1
LLVM version: 3.9

brian@ip-10-145-43-250:~/dev/json-rust⟫ cargo +beta test --test value
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/value-55ec8405f708d290

running 43 tests
test array_len ... ok
test array_members ... ok
test array_members_mut ... ok
test array_contains ... ok
test array_members_mut_rev ... ok
test array_members_rev ... ok
test array_push ... ok
test array_remove ... ok
test as_fixed_point ... ok
test error_unexpected_character ... ok
test error_unexpected_token ... ok
test fmt_array ... ok
test error_unexpected_unicode_character ... ok
test fmt_boolean ... ok
test array_pop ... ok
test fmt_null ... ok
test fmt_number ... ok
test fmt_object ... ok
test index_by_str ... ok
test index_by_string ... ok
test index_mut_by_str ... ok
test index_by_string_ref ... ok
test index_mut_by_string ... ok
test index_mut_by_string_ref ... ok
test fmt_string ... ok
test is_as_boolean ... ok
test is_as_number ... ok
test is_as_string ... ok
test is_null ... ok
test is_empty ... ok
test is_false ... ok
test null_len ... ok
test is_true ... ok
test object_dump_minified ... ok
test object_entries ... ok
test object_dump_pretty ... ok
test object_entries_mut ... ok
test object_entries_mut_rev ... ok
test object_entries_rev ... ok
test object_len ... ok
test pretty_writer_generator ... ok
test writer_generator ... ok
error: process didn't exit successfully: `/mnt2/dev/json-rust/target/debug/deps/value-55ec8405f708d290` (signal: 11, SIGSEGV: invalid memory reference)

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

Note this is non-deterministic, happens 1/5 times for me perhaps.

cc @maciejhirsz

[alexcrichton]

Not a regression, looks like this nodeterministically happens on stable as well.

@maciejhirsz you're likely very interested in the segfault regardless!

[RReverser]

@alexcrichton @brson Why was this closed? (given that it's not resolved) If I experience very similar issue but with serde-json, on stable Rust, should I submit as a separate one or it's already known and tracked somewhere?

[alexcrichton]

@RReverser I closed this as it appears to be an existing bug, and it's not clear that it's actually a bug in the compiler. With unsafe blocks and an existing segfault it looks like the problem may lie in json-rust

[RReverser]

Hmm you mean unsafe blocks in json-rust itself? I'm experience issue which rather looks like happening after JSON was parsed by serde-json, and I'm trying to process resulting tree. Then it fails in seemingly random places, which looks like stack overflow which was not caught properly.

[RReverser]

To clarify - in that own procession code there is no unsafe blocks or whatever, just handling BTreeMap in a thread.

[alexcrichton]

@RReverser if you've got a segfault with no unsafe code, then that's definitely a bug! Could you open a second issue to track that? It's not clear that it'd be related to this issue itself.

[RReverser]

@alexcrichton Sure, just wanted to make sure it's not the same and/or known issue (given json as common denominator). I'm in process of trying to minimize example, trying to see how far I can get while preserving a bug.

[RReverser]

I was just trying to find similar issue and found this one and #34877, which looked like could or could not be related.

[alexcrichton]

Ok no worries. If you've got a larger code base to post feel free to do so and you can update with your minimization progress and I'm sure others will join in and help minimize as well!

[RReverser]

@alexcrichton Sounds great, thanks!

[RReverser]

D'oh, now that I spent two hours minimizing it, turns out that it's definitely similar to #34877. Basically even

fn main() {
    let a = [0; 10000000];
    for i in a.iter() {
        println!("{}", i);
    }
}

fails with such error, except the source of it might be much less obvious in a more complicated code that traverses a deep tree and thus also exhausts a stack.

I guess by design Rust is supposed to print the stack overflow warning in such case and not segfault? Or is this desired behavior?

[alexcrichton]

Ah yeah that's just #34877 in that LLVM doesn't support stack probes on all platforms yet. Once we have that it should get a nice error message!