Closed Bug 1506011 Opened 6 years ago Closed 6 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: → https://bugzilla.mozilla.org/show_bug.cgi?id=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: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.