Closed
Description
All of them seem to be failing with
==17818== Syscall param read(buf) points to unaddressable byte(s)
==17818== at 0x401A5C7: read (syscall-template.S:81)
==17818== by 0x4005ED6: open_verify.constprop.8 (dl-load.c:1923)
==17818== by 0x400621B: open_path (dl-load.c:2040)
==17818== by 0x4008FED: _dl_map_object (dl-load.c:2270)
==17818== by 0x400DA91: openaux (dl-deps.c:63)
==17818== by 0x4010463: _dl_catch_error (dl-error.c:187)
==17818== by 0x400E0C5: _dl_map_object_deps (dl-deps.c:254)
==17818== by 0x4003117: dl_main (rtld.c:1614)
==17818== by 0x4018594: _dl_sysdep_start (dl-sysdep.c:249)
==17818== by 0x4004EA9: _dl_start_final (rtld.c:308)
==17818== by 0x4004EA9: _dl_start (rtld.c:414)
==17818== by 0x4000CD7: ??? (in /lib/x86_64-linux-gnu/ld-2.21.so)
==17818== Address 0xffedf35c0 is on thread 1's stack
==17818== in frame #1, created by open_verify.constprop.8 (dl-load.c:1681)
==17818==
cc @rust-lang/compiler
cc @edunham - are we testing these on the bots?