Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debuginfo/issue22656 test assertion fails with LLDB 8 #64074

Closed
ranweiler opened this issue Sep 1, 2019 · 4 comments · Fixed by #64578
Closed

debuginfo/issue22656 test assertion fails with LLDB 8 #64074

ranweiler opened this issue Sep 1, 2019 · 4 comments · Fixed by #64578
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug.

Comments

@ranweiler
Copy link
Contributor

Problem

The test debuginfo/issue-22656 has the following failing assertion:

// lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct, y: 123, z: ZeroSizedStruct, w: 456 }

Note the g, so this is for an LLDB that is not rust-enabled.

Here's what I see in the failing test stdout:

---- [debuginfo-gdb+lldb] debuginfo/issue-22656.rs stdout ----
NOTE: compiletest thinks it is using LLDB version 800
NOTE: compiletest thinks it is using LLDB without native rust support
...
print zs
(issue_22656::StructWithZeroSizedField) $1 = StructWithZeroSizedField { x: ZeroSizedStruct { }, y: 123, z: ZeroSizedStruct { }, w: 456 }
...
Full dump
running 1 test
F
failures:

---- [debuginfo-gdb+lldb] debuginfo/issue-22656.rs stdout ----
NOTE: compiletest thinks it is using LLDB version 800
NOTE: compiletest thinks it is using LLDB without native rust support

error: line not found in debugger output: [...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct, y: 123, z: ZeroSizedStruct, w: 456 }
status: exit code: 0
command: "/bin/python2.7" "/home/joe/src/rust/src/etc/lldb_batchmode.py" "/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/a" "/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/issue-22656.debugger.script"
stdout:
------------------------------------------
LLDB batch-mode script
----------------------
Debugger commands script is '/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/issue-22656.debugger.script'.
Target executable is '/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/a'.
Current working directory is '/home/joe/src/rust'
Creating a target for '/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/a'
settings set auto-confirm true

version
lldb version 8.0.0
command script import /home/joe/src/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 'issue-22656.rs' --line 46
Breakpoint 1: where = a`issue_22656::main::h884ad816d93c48d2 + 89 at issue-22656.rs:46:4, address = 0x00000000000015e9
run
Hit breakpoint 1.1: where = a`issue_22656::main::h884ad816d93c48d2 + 89 at issue-22656.rs:46:4, address = 0x00005555555555e9, resolved, hit count = 1
Process 14229 stopped * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x00005555555555e9 a`issue_22656::main::h884ad816d93c48d2 at issue-22656.rs:46:4 43 w: 456 44 }; 45 -> 46 zzz(); // #break ^ 47 } 48 49 fn zzz() { () } Process 14229 launched: '/home/joe/src/rust/build/x86_64-unknown-linux-gnu/test/debuginfo/issue-22656/a' (x86_64)
print v
(alloc::vec::Vec<int>) $0 = vec![1, 2, 3]
print zs
(issue_22656::StructWithZeroSizedField) $1 = StructWithZeroSizedField { x: ZeroSizedStruct { }, y: 123, z: ZeroSizedStruct { }, w: 456 }
quit
None

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

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



failures:
    [debuginfo-gdb+lldb] debuginfo/issue-22656.rs

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 122 filtered out

So, it seems like LLDB 8 - even without built-in Rust support - does a better job than older versions when printing that local. It only fails to resolve the local var name zs.

It could be that we think there's something off about my local lldb. If not, and lldb 8+ is just doing a better job by default, we may need to refine the conditional assertions in the debuginfo tests, since they depend on debugger version.

Versions

Platform: x86-64 Linux
Distro: Void Linux
lldb: 8.0.0

My lldb version string:

$ lldb --version
lldb version 8.0.0

Note the absence of the string rust-enabled, which is what we look for in tools/compiletest/main.rs:extract_lldb_version to set lldb_native_rust.

@eddyb
Copy link
Member

eddyb commented Sep 9, 2019

cc @michaelwoerister I wonder if this is the no-assertions equivalent to #63784.

@michaelwoerister
Copy link
Member

Maybe this could be fixed by making the check a bit more lenient. [...] can be used as a wildcard in the check patterns. @ranweiler, would you mind giving this a try locally by changing the check to:

// lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct[...], y: 123, z: ZeroSizedStruct[...], w: 456 }

That version should work for both old and new versions of LLDB.

@mati865
Copy link
Contributor

mati865 commented Sep 10, 2019

Using code from comment above does fix the error for LLDB 8.0.1.

@michaelwoerister
Copy link
Member

I'd be happy to r+ a PR providing that fix.

@jonas-schievink jonas-schievink added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. labels Sep 10, 2019
@bors bors closed this as completed in 0fd7a2d Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants