lldb print error and crash

[chabapok]

I tried to debug wth lldb this code:

use std::collections::HashMap;

#[derive(Debug)]
enum En<'a> {
    None,
    Bar(&'a Bar<'a>),
}

#[derive(Debug)]
struct Bar<'a> {
    next: En<'a>,
}

fn main() {
    let mut all_objects = HashMap::new();
    let bar: Bar = Bar {
        next: En::None,
    };
    all_objects.insert(1, bar);
    let b1 = all_objects.get(&1).unwrap();
    println!("b1={:?}", b1); //line 22
    println!("end");
}

When try to set breakpoint to line 22 and print b1:

$ lldb target/debug/test
(lldb) target create "target/debug/test"
Current executable set to 'target/debug/test' (x86_64).
(lldb) b 22
Breakpoint 1: 2 locations.
(lldb) r
Process 11600 launched: '/home/chabapok/RustProjects/2/test1/target/debug/test' (x86_64)
Process 11600 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
    frame #0: 0x000055555556501f test`test::main at main.rs:22
   19  	    };
   20  	    all_objects.insert(1, bar);
   21  	    let b1 = all_objects.get(&1).unwrap();
-> 22  	    println!("b1={:?}", b1); //line 22
   23  	    println!("end");
   24  	}
(lldb) p b1
error: test DWARF DIE at 0x0000007c (class En) has a member variable 0x00000082 (RUST$ENCODED$ENUM$0$None) whose type is a forward declaration, not a complete definition.
Please file a bug against the compiler and include the preprocessed output for /home/chabapok/RustProjects/2/test1/./src/main.rs
Stack dump:
0.	HandleCommand(command = "p b1")
1.	<eof> parser at end of file
2.	Parse:41:1: Generating code for declaration '$__lldb_expr'
Segmentation fault (core dumped)

ubuntu 14.04, x64, rustc 1.18.0-nightly
llvm,clang,lldb builded from master branch

[michaelwoerister]

Thanks for the report, @chabapok!

This is strange. I'm pretty sure we never create forward declarations in debuginfo, since there is no such thing in Rust. Does the error also occur when you choose a different name for struct Bar (so that it doesn't have the same name as the enum variant Bar)?

[chabapok]

With different name for struct Bar (not the same as enum variants) lldb works well.

[michaelwoerister]

@chabapok Thanks for finding that out! That's very interesting and suggests that we can do something about this on our side.

[sanmai-NL]

For me (rustc 1.23.0-nightly (246a6d1 2017-11-23), lldb version 5.0.0):

error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
warning: (x86_64) ../target/debug/data_protection_control 0x001c6d31: DW_TAG_member bitfield named "(null)" has invalid bit offset (0x100000000) member will be ignored. Please file a bug against the compiler and include the preprocessed output for /home/sanmai/devel/gitlab.com/Structure-Systems/SE/Rust/data_protection_control_nodes/src/lib.rs

[tromey]

DWARF output for enums is being changed in #32920. However there is still a fallback mode that emits what is done now.

With different name for struct Bar (not the same as enum variants) lldb works well.

Looking a the DWARF I see this for struct Bar:

 <2><1c5f>: Abbrev Number: 20 (DW_TAG_structure_type)
    <1c60>   DW_AT_name        : (indirect string, offset: 0x95c9): Bar
    <1c64>   DW_AT_byte_size   : 8
    <1c65>   DW_AT_alignment   : 8

and a bit later, the enum and the variant:

 <2><1c72>: Abbrev Number: 18 (DW_TAG_union_type)
    <1c73>   DW_AT_name        : (indirect string, offset: 0x81dc): En
    <1c77>   DW_AT_byte_size   : 8
    <1c78>   DW_AT_alignment   : 8
...
 <2><1c85>: Abbrev Number: 20 (DW_TAG_structure_type)
    <1c86>   DW_AT_name        : (indirect string, offset: 0x95c9): Bar
    <1c8a>   DW_AT_byte_size   : 8
    <1c8b>   DW_AT_alignment   : 8

One idea would be to move the variant type definition to be a child of En. I'd prefer to do this after landing #54004 though.

Probably lldb is confused by having two types of the same name in the same scope. Another solution, once it is ready, is to switch to the rust-enabled lldb, which does not have this problem.

[tromey]

For me (rustc 1.23.0-nightly (246a6d1 2017-11-23), lldb version 5.0.0):

error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
warning: (x86_64) ../target/debug/data_protection_control 0x001c6d31: DW_TAG_member bitfield named "(null)" has invalid bit offset (0x100000000) member will be ignored.

See #32920 (comment) and #32920 (comment). These are bugs in rustc that will be fixed by #54004.

[shepmaster]

These are bugs in rustc that will be fixed

Doesn't appear fixed yet, even though the linked commits are present in 1.32:

error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: tokio_mvce DWARF DIE at 0x0005b9e3 (class closure) has a member variable 0x0005b9ea (__0) whose type is a forward declaration, not a complete definition.
Try compiling the source file with -fstandalone-debug
Segmentation fault: 11

$ rustc --version
rustc 1.32.0 (9fda7c223 2019-01-16)

$ lldb --version
lldb-1000.11.38.2
  Swift-4.2

[ckaran]

I'm getting the same error as above:

error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0

Unfortunately, I haven't been able to create a reduced test case, so I'm not too sure what to do to help in debugging this.

Meta

Linux Dissertation 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:32:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 19.04
Release:	19.04
Codename:	disco

rustc 1.38.0-nightly (4b65a86eb 2019-07-15)
binary: rustc
commit-hash: 4b65a86ebace8600c8e269e8bfe3365cdc460e68
commit-date: 2019-07-15
host: x86_64-unknown-linux-gnu
release: 1.38.0-nightly
LLVM version: 8.0

cargo 1.38.0-nightly (677a180f4 2019-07-08)
release: 1.38.0
commit-hash: 677a180f4c8ca1dcef594f68dd0e63e4f08621f5
commit-date: 2019-07-08

[kornelski]

On macOS 10.15 Beta (19A526h), with both rustc 1.36.0 (a53f9df 2019-07-03) and rustc 1.38.0-nightly (b0e40bf 2019-08-02) I'm getting:

DWARF DIE at 0x000863a6 (class closure) has a member variable 0x000863ad (__0) whose type is a forward declaration, not a complete definition.

I can send you the file(s) if that helps.

(cc #57822)

[pnkfelix]

I suspect some people may be ending up here due to the diagnostic: "error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0"

But I think this bug as written is not focused on that detail, but rather than the issue that lldb itself is crashing.

(I may file a separate issue about the DW_TAG_base_type '()' thing, if only to get a dedicated thread about its importance or lack thereof.)

[chadbrewbaker]

I just got that error today. Running this tutorial https://mahdi.blog/rust-box-str-vs-string/ - when you get to the "thread backtrace".