Closed Bug 1506011 Opened 6 years ago Closed 5 years ago

Rust standard library source info broken in symbol files / crash reports

Categories

(Firefox Build System :: Toolchains, defect)

Product:
Firefox Build System
Component:
Toolchains
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Atoll, Unassigned)

References

Details

Hi, in https://crash-stats.mozilla.com/report/index/ce389eb2-6c02-4e39-af63-25d3c0181107#tab-details there is a link:

    <a href="https://hg.mozilla.org/mozilla-central/annotate/a6493a0b53a3d8df5c23b1300591f1f7ebc573e4/libcore/slice/mod.rs#l2046">libcore/slice/mod.rs:2046</a>

That link, however, does not return a valid result at HG:

https://hg.mozilla.org/mozilla-central/annotate/a6493a0b53a3d8df5c23b1300591f1f7ebc573e4/libcore/slice/mod.rs#l2046

    An error occurred while processing your request
    
    libcore/slice/mod.rs@a6493a0b53a3: not found in manifest 

I don't know enough HG to debug this further, but it seems like this should either be fixed to a working link or de-linked entirely.

Of the links I tested, this occured at _least_ with:

    libstd/thread/mod.rs
    libcore/slice/mod.rs

And it did _not_ occur with:

    gfx/webrender/src/render_backend.rs:306
Looks like libcore/ isn't in that tree. The data we get back from symbolication is this:

{
    "file": "hg:hg.mozilla.org/mozilla-central:libcore/slice/mod.rs:a6493a0b53a3d8df5c23b1300591f1f7ebc573e4",
    "frame": 9,
    "function": "webrender::clip_scroll_tree::ClipScrollTree::get_relative_transform",
    "function_offset": "0x785",
    "line": 2046,
    "module": "XUL",
    "module_offset": "0x333085",
    "offset": "0x1130f7085",
    "trust": "cfi"
}

So it kind of seems like the "file" value is wrong. I'm not sure why that would be or what this thing is specifically, but maybe it's a problem caused when generating symbols?

Ted: Any idea why the "file" value is wrong?
Flags: needinfo?(ted)
This is almost assuredly a bug with how we dump symbols.
Component: Webapp → Crash Reporting
Product: Socorro → Toolkit
The symbol file shows the FILE line as given in the raw dump in comment 1:
FILE 7475 hg:hg.mozilla.org/mozilla-central:libcore/slice/mod.rs:a6493a0b53a3d8df5c23b1300591f1f7ebc573e4

I'll have to see what the original debug info for this function looks like.
Flags: needinfo?(ted)
This seems like a rustc bug. I grabbed the dSYM for the build matching the crash in comment 0:
https://s3-us-west-2.amazonaws.com/org.mozilla.crash-stats.symbols-public/v1/XUL/41BB792AAA643BD08130D6806B7FC31F0/XUL.dSYM.tar.bz2

I used dwarfdump to dump the debug info for the function in comment 1:
dwarfdump --show-children -f 'get_relative_transform' XUL.dSYM/Contents/Resources/DWARF/XUL

There are a number of inlined subroutines in this function (many of them from libstd/libcore), and libcore/slice/mod.rs does show up:
0x00da2d5b:                 TAG_inlined_subroutine [33] *
                             AT_abstract_origin( {0x00ba4e2b}"_ZN68_$LT$usize$u20$as$u20$core..slice..SliceIndex$LT$$u5b$T$u5d$$GT$$GT$5index17h523f7c9917a8ab53E" )
                              AT_MIPS_linkage_name( "_ZN68_$LT$usize$u20$as$u20$core..slice..SliceIndex$LT$$u5b$T$u5d$$GT$$GT$5index17h523f7c9917a8ab53E" )
                              AT_name( "index<webrender::spatial_node::SpatialNode>" )
                              AT_decl_file( "libcore/slice/mod.rs" )
                              AT_decl_line( 2044 )

Notably it seems to be missing the full source path there, so we're treating it as a relative source path. The CU shows the topsrcdir as its compile dir, so these paths get turned into absolute paths using that:

0x00a8faa2: TAG_compile_unit [4] *
             AT_producer( "clang LLVM (rustc version 1.30.0 (da5f414c2 2018-10-24))" )
             AT_language( DW_LANG_Rust )
             AT_name( "gfx/webrender/src/lib.rs/@/webrender.6ckpbf2h-cgu.0" )
             AT_stmt_list( 0x0019bff5 )
             AT_comp_dir( "/builds/worker/workspace/build/src" )
Component: Crash Reporting → Toolchains
Product: Toolkit → Firefox Build System
I fixed something similar to this in rustc a while ago:
https://github.com/rust-lang/rust/issues/34179

Maybe it broke again, or broke in certain circumstances?
I wrote a simple testcase:
```
#[inline(never)]
fn f(o: Option<i32>) {
    let v: Vec<i32> = o.into_iter().collect();
    ::std::process::exit(v[0]);
}
```

With rustc 1.30.0 I get relative paths like above:

0x000009e5:                 TAG_inlined_subroutine [24] *
                             AT_abstract_origin( {0x00000882}"_ZN86_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..iter..traits..FromIterator$LT$T$GT$$GT$9from_iter17h71c9a6090ab644d4E" )
                             AT_low_pc( 0x0000000100000ee4 )
                             AT_high_pc( 0x0000000100000f21 )
                             AT_call_file( "libcore/iter/iterator.rs" )
                             AT_call_line( 1415 )




With rustc 1.29.0 I get absolute paths:

0x00001805:                 TAG_inlined_subroutine [20] *
                             AT_abstract_origin( {0x00001516}"_ZN86_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..iter..traits..FromIterator$LT$T$GT$$GT$9from_iter17h24c085ec1da32c85E" )
                             AT_ranges( 0x00000150
                                [0x0000000100001774 - 0x00000001000017cb)
                                [0x000000010000180e - 0x000000010000181d)
                                 End )
                             AT_call_file( "/Users/travis/build/rust-lang/rust/src/libcore/iter/iterator.rs" )
                             AT_call_line( 1415 )


So this seems to have regressed between Rust 1.29 and 1.30.
Blocks: 1500263
Flags: needinfo?(mwoerister)
This might have been fixed by https://github.com/rust-lang/rust/pull/54626. Does it reproduce with nightly Rust?
Flags: needinfo?(mwoerister)
It does seem fixed in rustc 1.33.0-nightly (d99a320cb 2018-12-18):

0x00000cc2:                 TAG_inlined_subroutine [29] *
                             AT_abstract_origin( {0x0000051a}"_ZN86_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..iter..traits..FromIterator$LT$T$GT$$GT$9from_iter17h2ec1283627ac0fd5E" )
                             AT_low_pc( 0x0000000100000a54 )
                             AT_high_pc( 0x0000000100000a91 )
                             AT_call_file( "/rustc/d99a320cba42f661aebfa1293b7b2ec3603dda75/src/libcore/iter/iterator.rs" )
                             AT_call_line( 1478 )

Would it be possible to get that fix backported to beta so we don't have to wait 2 more release cycles for it?
Oh, it looks like this has already been landed on beta, so that's good! Testing with rustc 1.32.0-beta.2 (a01e4761a 2018-12-08) shows that it works properly.
Summary: Invalid HG annotation links from my crash report → Rust standard library source info broken in symbol files / crash reports
Awesome :)
While looking into this I realized that we never fixed our source mapping to account for the Rust change to map source paths to "/rustc/<sha>/", so I filed bug 1515326 for that.
See Also: → 1515326
It would have been nice if this fix had been included in 1.31.1...

I verified that this is fixed in recent nightlies since the update to Rust 1.32.

I looked at the most recent macos nightly:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=nightly&selectedJob=227132480

Downloaded its symbols.zip and looked at the symbols for the webrender::clip_scroll_tree::ClipScrollTree::get_relative_transform function that displayed the problem (as discussed in previous comments). I grabbed all the files mentioned in the source line data for that function:

awk '/webrender::clip_scroll_tree::ClipScrollTree::get_relative_transform/{flag=1;next}/^FUNC/{ if (flag == 1 ) exit} flag { print $4 }'  XUL/67EE4A4353B13E14989C2E0A368A25800/XUL.sym | sort -u 
|14865
15026
15349
15987
15993
16035
16041
16044
16047
17
5486
5529

Then grepped for all the FILE lines for those files:

$ rg '^FILE (14865|15026|15349|15987|15993|16035|16041|16044|16047|17|5486|5529) ' XUL/67EE4A4353B13E14989C2E0A368A25800/XUL.sym
19:FILE 17 hg:hg.mozilla.org/mozilla-central:<::std::macros::panic macros>:3a3e393396f418df1490aa0832d0c54fc353d522
5488:FILE 5486 hg:hg.mozilla.org/mozilla-central:gfx/wr/webrender/src/clip_scroll_tree.rs:3a3e393396f418df1490aa0832d0c54fc353d522
5531:FILE 5529 hg:hg.mozilla.org/mozilla-central:gfx/wr/webrender/src/util.rs:3a3e393396f418df1490aa0832d0c54fc353d522
14867:FILE 14865 hg:hg.mozilla.org/mozilla-central:third_party/rust/euclid/src/transform3d.rs:3a3e393396f418df1490aa0832d0c54fc353d522
15028:FILE 15026 hg:hg.mozilla.org/mozilla-central:third_party/rust/smallvec/lib.rs:3a3e393396f418df1490aa0832d0c54fc353d522
15351:FILE 15349 hg:hg.mozilla.org/mozilla-central:toolkit/library/rust/shared/lib.rs:3a3e393396f418df1490aa0832d0c54fc353d522
15989:FILE 15987 git:github.com/rust-lang/rust:src/liballoc/raw_vec.rs:9fda7c2237db910e41d6a712e9a2139b352e558b
15995:FILE 15993 git:github.com/rust-lang/rust:src/liballoc/vec.rs:9fda7c2237db910e41d6a712e9a2139b352e558b
16037:FILE 16035 git:github.com/rust-lang/rust:src/libcore/num/mod.rs:9fda7c2237db910e41d6a712e9a2139b352e558b
16043:FILE 16041 git:github.com/rust-lang/rust:src/libcore/option.rs:9fda7c2237db910e41d6a712e9a2139b352e558b
16046:FILE 16044 git:github.com/rust-lang/rust:src/libcore/ptr.rs:9fda7c2237db910e41d6a712e9a2139b352e558b
16049:FILE 16047 git:github.com/rust-lang/rust:src/libcore/slice/mod.rs:9fda7c2237db910e41d6a712e9a2139b352e558b

All the files in the Rust standard library are correctly pointing at the Rust GitHub repo now.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.