libgkrust.a(webrender_bindings-ee4f1448dc823c6b.webrender_bindings.7qjxnz4e-cgu.0.rcgu.o) DWARF DIE at 0x001b2d28 (class closure) has a member variable 0x001b2d2f (__0) whose type is a forward declaration, not a complete definition.

[jrmuizel]

Some idea as #36185

[jrmuizel]

Here's the broken object file.
webrender_bindings-ee4f1448dc823c6b.webrender_bindings.7qjxnz4e-cgu.0.rcgu.o.zip

[jrmuizel]

@philipc is this something that's easy for ddbug to check for and give more information about?

[philipc]

Maybe, but I don't understand what the problem is and what needs to be checked.

0x001b2d28:   DW_TAG_structure_type
                DW_AT_name      ("closure")
                DW_AT_byte_size (0x18)
                DW_AT_alignment (8)

0x001b2d2f:     DW_TAG_member
                  DW_AT_name    ("__0")
                  DW_AT_type    (0x001b2d3d "closure")
                  DW_AT_alignment       (8)
                  DW_AT_data_member_location    (DW_OP_plus_uconst 0x0)

0x001b2d3c:     NULL

0x001b2d3d:   DW_TAG_structure_type
                DW_AT_name      ("closure")
                DW_AT_byte_size (0x18)
                DW_AT_alignment (8)

0x001b2d44:     DW_TAG_member
                  DW_AT_name    ("__0")
                  DW_AT_type    (0x00064c79 "Vec<webrender_bindings::moz2d_renderer::Job>")
                  DW_AT_alignment       (8)
                  DW_AT_data_member_location    (DW_OP_plus_uconst 0x0)

0x001b2d51:     NULL

The type of 0x001b2d2f is 0x001b2d3d, and I don't know why it claims 0x001b2d3d is a forward declaration since its members are defined too.

[jrmuizel]

So the crash doesn't happen with rust-lldb, so this probably pretty low to fix. Otherwise it seems like the next steps would be to figure out what's going on in lldb's DWARFFastParserClang and why it's sad about our info.

[xixixao]

I have this occurring with rust-lldb.

Sample code:

extern crate rexpect;
use rexpect::session::spawn_command;
use std::process::Command;
use tempfile::*;

type R<T> = Result<T, Box<std::error::Error>>;
type Session = rexpect::session::PtySession;


#[test]
fn test() -> R<()> {
    let mut p = run(&["example.txt"])?;
    p.exp_regex("Deleting example.txt")?;
    p.exp_eof()?;
    Ok(())
}


fn run(args: &[&str]) -> R<Session> {
    let directory = tempdir()?;
    let directory_path = directory.path();
    let mut command = Command::new("./target/debug/rust-rm");
    command.args(args);
    command.current_dir(directory_path);
    println!("Tmp folder: {:?}", directory_path);
    let mut p = spawn_command(command, Some(2000))?;
    Ok(p)
}

And I'm stepping into the p.exp_regex call. I have rexpect installed locally via:

[patch.crates-io]
rexpect = { path = "../rexpect" }

and am running:

sudo rust-lldb target/debug/test-38093ee6c91e9277

I'm on macOS 10.14.2 with just installed cargo and rust (cargo 1.33.0 (f099fe94b 2019-02-12)).

[EricRahm]

@michaelwoerister It seems like #36185 has resurfaced. From what I understand this is causing some issues for WebRender devs.

[michaelwoerister]

I'm going to look into this asap. Thanks for the test case, @xixixao, that should be very helpful!

[michaelwoerister]

I can reproduce this on macOS and Linux. On Linux I can reproduce with a recent debug build of LLDB.

[michaelwoerister]

@rust-lang/compiler, maybe we should make this p-high. At least it's what I'll be working on until it's resolved.

[michaelwoerister]

I've been able to make some progress here. I was not able to pinpoint why exactly LLDB fails to load the type info for fields in question but for the test cases I had, the bug occurred only when LLDB tries to get the type information of fields in a closure environment. I tried debugging further but with my limited understanding of LLDB's codebase makes this very time-consuming.

So, for the time being I propose to implement a workaround: If we make rustc mark closure environment structs and their fields with DW_AT_artificial then LLDB does not hit the problematic code paths. Marking those fields as artificial is the right thing to do here anyway (we already do it for things like fields of slices). It's unfortunate that we don't know the exact problem in LLDB but the workaround would not be a hack. In my local testing this did not break any debuginfo tests for either LLDB or GDB.