Repository navigation
OSX linker segfaulting on Travis #38878
Description
Activity
Is there a way to collect the coredump from the segfault so we could attempt to track down the reason behind the segfault? Perhaps we could at least pass
-vto clang so we could try to reproduce locally?@Mark-Simulacrum your guess is as good as mine!
If you set
ulimit -c unlimited, the core dump will end up in/cores.- added a commit that references this issue
on Jan 12, 2017 https://travis-ci.org/rust-lang/rust/jobs/193795162 is the first job where we got a stack trace:
Core file '/cores/core.31933' (x86_64) was loaded. (lldb) command source -s 0 'cmds' Executing commands in '/Users/travis/build/rust-lang/rust/cmds'. (lldb) bt all * thread #1: tid = 0x0000, 0x00007fffaed8519d libsystem_c.dylib`__cxa_finalize_ranges + 369, stop reason = signal SIGSTOP * frame #0: 0x00007fffaed8519d libsystem_c.dylib`__cxa_finalize_ranges + 369 thread #2: tid = 0x0001, 0x000000010f9fe5b4 dyld`ImageLoaderMachO::findClosestSymbol(mach_header const*, void const*, void const**) + 264, stop reason = signal SIGSTOP frame #0: 0x000000010f9fe5b4 dyld`ImageLoaderMachO::findClosestSymbol(mach_header const*, void const*, void const**) + 264 frame #1: 0x000000010f9f5444 dyld`dladdr + 133 frame #2: 0x00007fffaeced99c libdyld.dylib`dladdr + 72 frame #3: 0x0000000100316647 ld`__assert_rtn + 207 frame #4: 0x00000001003653c4 ld`ld::tool::InputFiles::parseWorkerThread() + 696 frame #5: 0x00007fffaef07aab libsystem_pthread.dylib`_pthread_body + 180 frame #6: 0x00007fffaef079f7 libsystem_pthread.dylib`_pthread_start + 286 frame #7: 0x00007fffaef07221 libsystem_pthread.dylib`thread_start + 13I wouldn't necessarily call that... illuminating
I wonder if there would be a way to print what the files we're linking are? Maybe that would help since maybe the linker segfaults on an improperly formatted file or something like that; knowing what the files are (names and lengths) may help. I think passing
-vto clang would be good enough, at least as a start.PRs are always welcome! I don't have any magical tricks up my sleeves to implement tricks like that unfortunately.
Next successful stack trace: https://travis-ci.org/rust-lang/rust/jobs/194499380
Core file '/cores/core.33216' (x86_64) was loaded. (lldb) command source -s 0 'cmds' Executing commands in '/Users/travis/build/rust-lang/rust/cmds'. (lldb) bt all * thread #1: tid = 0x0000, 0x00007fffbb6ec19d libsystem_c.dylib`__cxa_finalize_ranges + 369, stop reason = signal SIGSTOP frame #0: 0x00007fffbb6ec19d libsystem_c.dylib`__cxa_finalize_ranges + 369 * thread #2: tid = 0x0001, 0x00007fffbb786756 libsystem_kernel.dylib`close + 10, stop reason = signal SIGSTOP frame #0: 0x00007fffbb786756 libsystem_kernel.dylib`close + 10 frame #1: 0x0000000106869c10 ld`Snapshot::createSnapshot() + 270 frame #2: 0x00000001067ac5da ld`__assert_rtn + 98 frame #3: 0x00000001067fb3c4 ld`ld::tool::InputFiles::parseWorkerThread() + 696 frame #4: 0x00007fffbb86eaab libsystem_pthread.dylib`_pthread_body + 180 frame #5: 0x00007fffbb86e9f7 libsystem_pthread.dylib`_pthread_start + 286 frame #6: 0x00007fffbb86e221 libsystem_pthread.dylib`thread_start + 13another failure of this kind https://travis-ci.org/rust-lang/rust/jobs/201327443#L4808
These look like assertion failures:
frame #2: 0x0000000107ac45da ld`__assert_rtn + 98 frame #3: 0x00000001067fb3c4 ld`ld::tool::InputFiles::parseWorkerThread() + 696Now the question is how we recover the assert message. Any Mac person knows of a way?
4 remaining items
- added a commit that references this issue
on Mar 10, 2017 - added 2 commits that reference this issue
on Mar 10, 2017 - added a commit that references this issue
on Mar 11, 2017 Looks like #40422 did the trick, we haven't seen this in ~2 weeks, so closing.
- added a commit that references this issue
on Nov 18, 2017
I've seen this quite a lot recently
Example logs:
Example Travis runs:
I'm opening a tracking issue so we can collect some more logs and hopefully draw conclusions from them at some point. Until then I'm not really sure how we'd deal with this...