Linker error for doc tests on Travis-CI

[TheDan64]

Had to mark certain doc tests as no_run because they were throwing a linking error on travis (possibly due to LLVM?) I could not reproduce on either of my local machines.

[71]

Doesn't happen on my machine either.

[71]

The logs show that the error comes from a SIGKILL signal, so one can guess that Travis is purposely killing the process. Maybe limiting the number of concurrent tests (using cargo test -- --test-threads 1) might fix things?

[71]

Some tests

I used the time -v command to see if there was a big difference between the tests that crash, and the ones that don't. In every case, the project needed to be built beforehand.

With the ExecutionEngine::add_global_mapping tests

        Command being timed: "cargo test"
    User time (seconds): 87.06
    System time (seconds): 87.98
    Percent of CPU this job got: 359%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.66
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 357852
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 2864079
    Voluntary context switches: 0
    Involuntary context switches: 0
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

Without

        Command being timed: "cargo test"
    User time (seconds): 85.96
    System time (seconds): 83.15
    Percent of CPU this job got: 328%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:51.52
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 361876
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 2796557
    Voluntary context switches: 0
    Involuntary context switches: 0
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

Memory consumption / run-time is basically the same, and I'm as lost as ever. Although the building / testing phase does use a lot of resources.

[TheDan64]

I don't think add_global_mapping is the issue here specifically but rather rustdoc running doctests which contain certain subsets of LLVM. Like, I think builders and modules had issues but not context (IIRC)

[71]

Oh, yes, that's what I think as well. I compared to add_global_mapping as an example, since this test (and most if not all other tests) requires some JIT compilation.

[joecorcoran]

Hey @TheDan64, sorry you're having trouble here. I was just browsing some Rust/LLVM projects and came across this issue! If it'd help you to be able to inspect this issue directly on the build machine, I've just enabled debug builds for this repo on Travis CI. This means you can SSH into a running build via tmate. Drop me a line at joe@travis-ci.org if you want me to walk you through it.

[TheDan64]

Thanks @joecorcoran!! I really appreciate that!

[nlewycky]

In PR #109, I'm marking more doc tests as no_run due to what we think is the same issue. The problem is a SIGSEGV in the _bfd_elf_gc_mark_extra_sections function in the version of ld.bfd shipped in Xenial GNU ld (GNU Binutils for Ubuntu) 2.26.1. That function is only called when --gc-sections is enabled, so you can work around the crash if you rerun the link line with an additional --no-gc-sections. Another workaround is to build your own ld.bfd from the binutils git head, tested at d88bdcb4a52bc041ed9b607dda22f478ec61a67b.