debuginfo-lldb test failures with lldb 350 on OS X

[tedhorst]

I upgraded to Xcode 7.3 which includes lldb version 350.0.21.3. When running make check, all the debuginfo-lldb tests fail like this:

thread '[debuginfo-lldb] debuginfo-lldb/vec-slices.rs' panicked at 'explicit panic', /Users/ted/Developer/OpenSource/Rustlang/rust/src/compiletest/runtest.rs:1676

---- [debuginfo-lldb] debuginfo-lldb/vec.rs stdout ----
    NOTE: compiletest thinks it is using LLDB version 350

error: Error while running LLDB
status: signal: 11
command: "/usr/bin/python2.7" "/Users/ted/Developer/OpenSource/Rustlang/rust/src/etc/lldb_batchmode.py" "x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin" "x86_64-apple-darwin/test/debuginfo-lldb/vec.debugger.script"
stdout:
------------------------------------------
LLDB batch-mode script
----------------------
Debugger commands script is 'x86_64-apple-darwin/test/debuginfo-lldb/vec.debugger.script'.
Target executable is 'x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin'.
Current working directory is '/Users/ted/Developer/OpenSource/Rustlang/rust/build'
Creating a target for 'x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin'
settings set auto-confirm true

version
lldb-350.0.21.3 
command script import /Users/ted/Developer/OpenSource/Rustlang/rust/./src/etc/lldb_rust_formatters.py
type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
type category enable Rust

breakpoint set --line 45
error: No selected frame to use to find the default file.
error: No file supplied and no default file available.

run
Process 97454 exited with status = 0 (0x00000000) Process 97454 launched: '/Users/ted/Developer/OpenSource/Rustlang/rust/build/x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin' (x86_64) 
print a
error: use of undeclared identifier 'a'
error: 1 errors parsing expression

quit


------------------------------------------
stderr:
------------------------------------------

------------------------------------------

I can fix this by specifying the source file name in the breakpoint command, but then I get a different failure:

thread '[debuginfo-lldb] debuginfo-lldb/vec-slices.rs' panicked at 'explicit panic', /Users/ted/Developer/OpenSource/Rustlang/rust/src/compiletest/runtest.rs:1676

---- [debuginfo-lldb] debuginfo-lldb/vec.rs stdout ----
    NOTE: compiletest thinks it is using LLDB version 350

error: Error while running LLDB
status: signal: 11
command: "/usr/bin/python2.7" "/Users/ted/Developer/OpenSource/Rustlang/rust/src/etc/lldb_batchmode.py" "x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin" "x86_64-apple-darwin/test/debuginfo-lldb/vec.debugger.script"
stdout:
------------------------------------------
LLDB batch-mode script
----------------------
Debugger commands script is 'x86_64-apple-darwin/test/debuginfo-lldb/vec.debugger.script'.
Target executable is 'x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin'.
Current working directory is '/Users/ted/Developer/OpenSource/Rustlang/rust/build'
Creating a target for 'x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin'
settings set auto-confirm true

version
lldb-350.0.21.3 
command script import /Users/ted/Developer/OpenSource/Rustlang/rust/./src/etc/lldb_rust_formatters.py
type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
type category enable Rust

breakpoint set --file vec.rs --line 45
Breakpoint 1: where = vec.stage2-x86_64-apple-darwin`vec::main::h28e3360ac59a9f54 + 138, address = 0x0000000100000e3a 
run
Hit breakpoint 1.1: where = vec.stage2-x86_64-apple-darwin`vec::main::h28e3360ac59a9f54 + 138, address = 0x0000000100000e3a, resolved, hit count = 1 
Process 17835 stopped * thread #1: tid = 0x9f207, 0x0000000100000e3a vec.stage2-x86_64-apple-darwin`vec::main::h28e3360ac59a9f54 + 138 at vec.rs:45, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100000e3a vec.stage2-x86_64-apple-darwin`vec::main::h28e3360ac59a9f54 + 138 at vec.rs:45 42 VECT[2] = 6; 43 } 44 -> 45 zzz(); // #break 46 } 47 48 fn zzz() {()} Process 17835 launched: '/Users/ted/Developer/OpenSource/Rustlang/rust/build/x86_64-apple-darwin/test/debuginfo-lldb/vec.stage2-x86_64-apple-darwin' (x86_64) 
print a
quit


------------------------------------------
stderr:
------------------------------------------

------------------------------------------

Nothing is printed by the print command. This happens with or without the formatters.

[michaelwoerister]

That's strange. I'll have to get ahold of an OSX system in order to look into that.
Thanks for the bug report, @tedhorst!

[michaelwoerister]

Update: I was able to reproduce this issue.

[indutny]

Hello!

Not sure how much it will help, but I was investigating similar crashes with llnode, and it turns out that lldb is lying when reporting its version:

lldb-350.0.21.3

In fact it is more compatible to 380, because this commit is present there. I was able to tell that after checking the disassembly of lldb and offsets in vtable that it expects.

Anyway, hope this helps!

[jonathandturner]

+1 on this issue.

I'm finding this is pretty bad for compiler contributors who work on the latest mac. The end result tends to be that "make check" fails, and you're left running all the various checks that run after debuginfo-lldb run by hand.

We could put debuginfo-lldb last, so at the very least the other tests run first.

[tedhorst]

I have been using @michaelwoerister's closed pull request #33097, and it is working for me (passes full make check).

[jonathandturner]

@tedhorst which lldb are you on? I'm on lldb-350.0.21.9 and I'm still seeing the issue.

[tedhorst]

I'm on the same. I have just been merging #33097 into master, and it has been working for a while. Which issue are you seeing?

[jonathandturner]

@tedhorst - oh I missed it wasn't merged yet. I'm seeing:

running 102 tests
test [debuginfo-lldb] debuginfo-lldb/associated-types.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/basic-types-globals-metadata.rs ... ok
test [debuginfo-lldb] debuginfo-lldb/basic-types-globals.rs ... ok
test [debuginfo-lldb] debuginfo-lldb/basic-types-metadata.rs ... ok
test [debuginfo-lldb] debuginfo-lldb/basic-types-mut-globals.rs ... ok
test [debuginfo-lldb] debuginfo-lldb/basic-types.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-basic.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-c-style-enum.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-enum.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-struct.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-tuple.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/borrowed-unique-basic.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/box.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/boxed-struct.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/by-value-non-immediate-argument.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/by-value-self-argument-in-trait-impl.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/c-style-enum-in-composite.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/c-style-enum.rs ... FAILED
test [debuginfo-lldb] debuginfo-lldb/closure-in-generic-function.rs ... FAILED

[tedhorst]

Do you still get the failures after merging #33097? You may need to do a make clean, not sure.

[michaelwoerister]

I'm finding this is pretty bad for compiler contributors who work on the latest mac.

If I understand this and this right, the latest version of LLDB distributed with XCode should already contain the fix and things should work again.

What we could do to mitigate this problem in the meantime is to collect version strings of LLDB versions that don't work and explicitly warn people that they should update, or disable LLDB-based tests if a version known to be broken is found.