Skip to content

SIGSEGV: invalid memory reference in Rust tests #604

@mati865

Description

@mati865

Rust by default uses LLD via its own wrapper, so it takes a bit of persuasion to actually use wild.

The easiest way to reproduce it currently is by modifying config.toml/bootstrap.toml to:

[rust]
lld = false

I also build LLVM from source by setting download-ci-llvm = false but that shouldn't matter.

Then run the problematic test:

❯ PATH=~/Projects/wild:$PATH ./x.py t coretests -- "ilog10_u128"
...
     Running tests/lib.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-ed4ed2eafac4a1eb)

running 1 tests
error: test failed, to rerun pass `-p coretests --test coretests`

Caused by:
  process didn't exit successfully: `/home/mateusz/Projects/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-ed4ed2eafac4a1eb ilog10_u128 --quiet -Z unstable-options --format json` (signal: 11, SIGSEGV: invalid memory reference)
Build completed unsuccessfully in 0:05:00

GDB wasn't very helpful and interleaves the output with hundreds of warning: (Internal error: pc 0x555555742d0c in read in CU, but not in symtab.) but LLDB is more useful in my case:

❯ LD_LIBRARY_PATH="." lldb -- ./bin ilog10_u128
(lldb) target create "./bin"
Current executable set to '/home/mateusz/rust/1/bin' (x86_64).
(lldb) settings set -- target.run-args  "ilog10_u128"
(lldb) breakpoint set --name coretests::num::int_log::ilog10_u128
Breakpoint 1: where = bin`coretests::num::int_log::ilog10_u128::h5743851781febd6f + 27 at int_log.rs:195, address = 0x00000000001ee64b
(lldb) r
Process 1624725 launched: '/home/mateusz/rust/1/bin' (x86_64)

...
Process 1628529 stopped
* thread #2, name = 'num::int_log::i', stop reason = instruction step into
    frame #0: 0x00005555556bafec bin.ref-linker`coretests::num::int_log::ilog10_u128::h5743851781febd6f [inlined] core::num::int_log10::u128::h7203bcbacaf2b2be(val=<unavailable>) at int_log10.rs:87:8
   84  	        log += 32;
   85  	        return log + u32(val as u32);
   86  	    }
-> 87  	    if val >= 10_000_000_000_000_000 {
    	       ^
   88  	        val /= 10_000_000_000_000_000;
   89  	        log += 16;
   90  	    }
(lldb) stepi
Process 1628529 stopped
* thread #2, name = 'num::int_log::i', stop reason = instruction step into
    frame #0: 0x00007ffff7dcf570 libgcc_s.so.1`__udivti3(n=<unavailable>, d=10000000000000000) at libgcc2.c:1299:1

So, let's check __udivti3:

❯ readelf -Ws bin | rg __udivti3
   159: 0000000000000000   201 FUNC    WEAK   HIDDEN   UND __udivti3

❯ readelf -Ws bin.ref-linker | rg __udivti3
   327: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __udivti3
  6878: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __udivti3

Yeah, that symbol surely shouldn't be weak nor hidden.

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions