issue-13560.rs is flaky on 64-bit OSX

[alexcrichton]

Tracking issue for this failure:

failures:

---- [pretty] run-pass-fulldeps/issue-13560.rs stdout ----

error: auxiliary build of /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/test/auxiliary/issue-13560-3.rs failed to compile: 
status: exit code: 101
command: x86_64-apple-darwin/stage2/bin/rustc /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/test/auxiliary/issue-13560-3.rs -L x86_64-apple-darwin/test/run-pass-fulldeps --target=x86_64-apple-darwin -L x86_64-apple-darwin/test/run-pass-fulldeps/issue-13560.stage2-x86_64-apple-darwinlibaux --out-dir x86_64-apple-darwin/test/run-pass-fulldeps/issue-13560.stage2-x86_64-apple-darwinlibaux --cfg rtopt --cfg debug -L x86_64-apple-darwin/rt
stdout:
------------------------------------------
task 'rustc' panicked at 'index out of bounds: the len is 2952 but the index is 2952', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/librbml/lib.rs:155



------------------------------------------
stderr:
------------------------------------------
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace

------------------------------------------

task '[pretty] run-pass-fulldeps/issue-13560.rs' panicked at 'explicit panic', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/compiletest/runtest.rs:1487

[alexcrichton]

It appears that the compiler is producing corrupt metadata somehow. I have modified the test to ignore issue-13560-1 and only link to issue-13560-2, and I've found an interesting phenomena. When running the test via make the rlib for -2 may end up containing two blobs of metadata. One blob of metadata ends in four 0x0a bytes (corrupted), and the other blob is the exact same but without these trailing bytes.

The compilation of the -3 crate is the one that's failing, and it will deterministically fail depending on the metadata of the -2 crate. I do not currently know where the extra bytes come from, still trying to track that down...