'Cannot append EBB that is already in the layout' panic when parsing test

[frewsxcv]

Found via #417

thread '<unnamed>' panicked at 'Cannot append EBB that is already in the layout', /Users/corey/dev/cranelift/lib/codegen/src/ir/layout.rs:339:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
==14696== ERROR: libFuzzer: deadly signal
    #0 0x10b7a6807 in __sanitizer_print_stack_trace (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x60807)
    #1 0x109e6836b in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp:233
    #2 0x109e6831d in fuzzer::Fuzzer::StaticCrashSignalCallback() FuzzerLoop.cpp:206
    #3 0x109ec6517 in fuzzer::CrashHandler(int, __siginfo*, void*) FuzzerUtilPosix.cpp:36
    #4 0x7fff52d7af59 in _sigtramp (libsystem_platform.dylib:x86_64+0x1f59)
    #5 0x7ffee691493f  (<unknown module>)
    #6 0x7fff52b181ad in abort (libsystem_c.dylib:x86_64+0x5d1ad)
    #7 0x109f08258 in panic_abort::__rust_start_panic::abort::h4267bf60cc0450c8 lib.rs:61
    #8 0x109f08248 in __rust_start_panic lib.rs:56
    #9 0x109efcf28 in rust_panic panicking.rs:511
    #10 0x109efcf0d in std::panicking::rust_panic_with_hook::hf5ff090f1c7b8b56 panicking.rs:483
    #11 0x1097a3a21 in std::panicking::begin_panic::hdaf3614ae8d1907c panicking.rs:397
    #12 0x1096075b7 in cranelift_codegen::ir::layout::Layout::append_ebb::hdb8927e7f5c78994 layout.rs:339
    #13 0x10936c917 in cranelift_reader::parser::Context::add_ebb::hf1570180b8976ac6 parser.rs:262
    #14 0x1093c1a27 in cranelift_reader::parser::Parser::parse_extended_basic_block::h86e63735f8edac5f parser.rs:1367
    #15 0x1093bd526 in cranelift_reader::parser::Parser::parse_function_body::h51c8843f214aa7bd parser.rs:1328
    #16 0x109391e6f in cranelift_reader::parser::Parser::parse_function::h4c459a107f630f9b parser.rs:805
    #17 0x10938ec50 in cranelift_reader::parser::Parser::parse_function_list::he94ab5eea4e77273 parser.rs:760
    #18 0x10936426b in cranelift_reader::parser::parse_test::he40e0e2610aa9218 parser.rs:54
    #19 0x1092e2553 in rust_fuzzer_test_input fuzz_reader_parse_test.rs:9
    #20 0x109e64558 in libfuzzer_sys::test_input_wrap::_$u7b$$u7b$closure$u7d$$u7d$::hbc101ef426c41f23 lib.rs:11
    #21 0x109e65970 in std::panicking::try::do_call::h4d3fd4d58a300f8a panicking.rs:310
    #22 0x109f0823b in __rust_maybe_catch_panic lib.rs:39
    #23 0x109e64e9c in std::panicking::try::hf9fe15a72767ed4c panicking.rs:289
    #24 0x109e65d4f in std::panic::catch_unwind::h7dc3709d1d7549fb panic.rs:374
    #25 0x109e63d5c in LLVMFuzzerTestOneInput lib.rs:9
    #26 0x109e6ae81 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:515
    #27 0x109e6a2da in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) FuzzerLoop.cpp:440
    #28 0x109e70573 in fuzzer::Fuzzer::MutateAndTestOne() FuzzerLoop.cpp:648
    #29 0x109e72e48 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) FuzzerLoop.cpp:775
    #30 0x109eb1fd1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:754
    #31 0x109edeeef in main FuzzerMain.cpp:20
    #32 0x7fff52a6c014 in start (libdyld.dylib:x86_64+0x1014)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 5 ChangeASCIIInt-ChangeBinInt-CopyPart-ShuffleBytes-EraseBytes-; base unit: 3a95f94f665fa842b8d7cdee8c01e0957060b055
artifact_prefix='/Users/corey/dev/cranelift/fuzz/artifacts/fuzz_reader_parse_test/'; Test unit written to /Users/corey/dev/cranelift/fuzz/artifacts/fuzz_reader_parse_test/crash-6d01f881bddc42f04264d6bdd406a54d04220c7a

Here's the string that causes the panic:

let s = b"; Test the division legalizttions.\ntest legalizer\n; See also legalize-div-traps.clif.\nset avoid_div_traps=0\ntarget x86_64\n\n; regex: V=v\\d+\n; regex: EBB=ebb\\d+\n\nfunction %udiv(i64, i64) -> i64 {\nebb0(v0: i64, v1: i64):\n    ; check: ebb0(\n    v2 = udiv v0, v1\n    ; nextln: $(hi=$V) = iconst.i64 0\n    ; nextln: $(d=$V), $(r=$V) = x86_udivmodx v0, $hi, v1\n    return v2\n    ; 28, i64) -> i64 {\nebb0(v0: i64, v1: i64):\n    ; check: ebb0(\n    v2 = srem v0, v1\n    ; nextln: $(fm1=$V) = ifcmp_imm v1, -1\n    ; nextln: brif eq $fm1, $(m1=$EBB)\n    ; check: $(hi=$V) = sshr_imm\n    ; nextln: $(d=$V), $(r=$V) = x86_sdivmodx v0, $hi, v1\n    ; nextln: jump $(done=$EBB)($r)\n    ; check: $m1:\n    ; nextln: $(zero=$V) = iconst.i64 0\n    ; nextln: jump $(done=$ x86_udivmodx v ; check: $done(v2: i64):\n    return v2\n    ; nextln: return v2\n}\n";

[sunfishcode]

The input defines two ebb0s, which isn't valid. The parser should diagnose that rather than panicking.

[XAMPPRocky]

@sunfishcode Hey, I'd like to take this issue. Can I get some pointers as to what is required to fix this?

[sunfishcode]

Sure! Take a look in lib/reader/src/parser.rs, in add_ebb. The def_ebb call will diagnose duplicate definitions, so we should do that before starting to modify the function.

[sunfishcode]

Also, we should probably make similar changes to the other add_* functions.