Spurious LLDB segfault (signal 11)

[kennytm]

Symptom: debuginfo-lldb tests failed with signal 11. Only happens on macOS (others use GDB) and usually i686, and only one test is failing.

Example logs (look for "status: signal: 11"):

[01:40:10] failures:
[01:40:10] 
[01:40:10] ---- [debuginfo-lldb] debuginfo/lexical-scopes-in-block-expression.rs stdout ----
[01:40:10] 	NOTE: compiletest thinks it is using LLDB version 360
[01:40:10] 
[01:40:10] error: Error while running LLDB
[01:40:10] status: signal: 11
[01:40:10] command: "/usr/bin/python" "/Users/travis/build/rust-lang/rust/src/etc/lldb_batchmode.py" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/test/debuginfo/lexical-scopes-in-block-expression.stage2-x86_64-apple-darwin" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/test/debuginfo/lexical-scopes-in-block-expression.debugger.script"
[01:40:10] stdout:
[01:40:10] ------------------------------------------
[01:40:10] LLDB batch-mode script
[01:40:10] ----------------------
...

Affected PRs:

• Turn trans_fulfill_obligation into a query #44967 (comment) (x86_64-apple-darwin :: lexical-scopes-in-block-expression.rs)
• Rollup of 5 pull requests #45192 (comment) (i686-apple-darwin :: by-value-non-immediate-argument.rs)
• Rollup of 9 pull requests #45141 (comment) (i686-apple-darwin :: self-in-generic-default-method.rs)
• rustbuild: Compile the error-index in stage 2 #44605 (comment) (i686-apple-darwin :: lexical-scope-in-unique-closure.rs)
• expand on using rustup custom toolchains in CONTRIBUTING.md #44194 (comment) (i686-apple-darwin :: static-method-on-struct-and-enum.rs)
• rustc: Capture diagnostics from all queries #44046 (comment) (x86_64-apple-darwin :: generic-method-on-generic-struct.rs)
• redox: Correct error on exec when file is not found #44000 (comment) (x86_64-apple-darwin :: name-shadowing-and-scope-nesting.rs)
• rustdoc: Hide self: Box<Self> in list of deref methods #42394 (comment) (i686-apple-darwin :: lexical-scope-in-if.rs)

Related: #42693 (GDB failed due to ERROR_NOT_ENOUGH_QUOTA on Windows)

[Mark-Simulacrum]

I wasn't able to reproduce the failure locally, but it seems like the problem might be with Python segfaulting, not LLDB. Below is the crashes log from #44967 (comment), and the first one seems to indicate that Python crashed. Maybe we can print that failure out or something? It seems possible that our Python batchmode script or our formatter script for LLDB has some thread race or something like that that causes the crash here....

�[0K$ ls $HOME/Library/Logs/DiagnosticReports/
Python_2017-10-12-005820_Traviss-Mac-28.crash
abort-link-to-unwinding-crates.stage2-x86_64-apple-darwin_2017-10-12-004319_Traviss-Mac-28.crash
abort.stage2-x86_64-apple-darwin_2017-10-12-004318_Traviss-Mac-28.crash
backtrace.stage2-x86_64-apple-darwin_2017-10-12-003318-1_Traviss-Mac-28.crash
backtrace.stage2-x86_64-apple-darwin_2017-10-12-003318_Traviss-Mac-28.crash
com.apple.CoreSimulator.CoreSimulatorService_2016-11-16-181716_Traviss-Mac.crash
issue-24313.stage2-x86_64-apple-darwin_2017-10-12-003832_Traviss-Mac-28.crash
lto-abort.stage2-x86_64-apple-darwin_2017-10-12-004323_Traviss-Mac-28.crash
out-of-stack.stage2-x86_64-apple-darwin_2017-10-12-004302-1_Traviss-Mac-28.crash
out-of-stack.stage2-x86_64-apple-darwin_2017-10-12-004302-2_Traviss-Mac-28.crash
out-of-stack.stage2-x86_64-apple-darwin_2017-10-12-004302_Traviss-Mac-28.crash
out-of-stack.stage2-x86_64-apple-darwin_2017-10-12-004303_Traviss-Mac-28.crash
running-with-no-runtime.stage2-x86_64-apple-darwin_2017-10-12-004425_Traviss-Mac-28.crash
segfault-no-out-of-stack.stage2-x86_64-apple-darwin_2017-10-12-004426_Traviss-Mac-28.crash
signal-exit-status.stage2-x86_64-apple-darwin_2017-10-12-004443_Traviss-Mac-28.crash
stack-probes-lto.stage2-x86_64-apple-darwin_2017-10-12-004515-1_Traviss-Mac-28.crash
stack-probes-lto.stage2-x86_64-apple-darwin_2017-10-12-004515_Traviss-Mac-28.crash
stack-probes.stage2-x86_64-apple-darwin_2017-10-12-004512-1_Traviss-Mac-28.crash
stack-probes.stage2-x86_64-apple-darwin_2017-10-12-004512_Traviss-Mac-28.crash

[kennytm]

Ooooohhhhh that's an interesting point. I was puzzled that why there's no LLDB crash log, turns out it is Python crashing! I'll try to cat the crash log if the filename doesn't contain "stage2".