File paths in DWARF are not absolute #44325
Comments
lrhn
added
the
area-vm
|
/cc @sstrickl |
|
@sstrickl thanks, where do I pass the |
|
@sstrickl I've tried adding the The issue is, AFAIK that these prefixes are different when specified in dwarf.cc in the Dart SDK but when integrated in Flutter, they're at a different path as seen here: // 'dart:ui' maps to /flutter/lib/ui
final String flutterRoot = fileSystem.path.join(flutterSdkRoot, 'bin', 'cache', 'pkg', 'sky_engine', 'lib', 'ui');
orgDartlangSdkMappings[flutterRoot] = Uri.parse('org-dartlang-sdk:///flutter/lib/ui');
// The rest of the Dart SDK maps to /third_party/dart/sdk
final String dartRoot = fileSystem.path.join(flutterSdkRoot, 'bin', 'cache', 'pkg', 'sky_engine');
orgDartlangSdkMappings[dartRoot] = Uri.parse('org-dartlang-sdk:///third_party/dart/sdk');What do you think would be the best way to get this working? |
|
If we'd be looking for the above In fact, an easier fix is probably to just literally strip off the |
|
Have created CL 268762 to do just that. |
|
Ah, but wait, I suppose we'd need to strip |
Before, we only stripped `org-dartlang-sdk:///` as a prefix when it was
followed by `sdk/...`, which happens for code compiled with the Dart
SDK. However, the same prefix can show up in Flutter code (e.g.,
`org-dartlang-sdk:///third_party/dart/sdk/...`). Thus, except for one
case, just strip the prefix at all times when `--resolve-dwarf-paths`
is set, leaving a relative path.
The one case is `org-dartlang-sdk:///flutter/`, which appears in the
resolved version of `dart:ui` (`org-dartlang-sdk:///flutter/lib/ui`),
where the `flutter` isn't part of the actual filesystem path. In this
case, we strip off the `flutter/` as well.
TEST=vm/dart{,_2}/use_resolve_dwarf_paths_flag
Bug: #44325
Change-Id: Ia9abca877e41657089a438d4723ff08a2e16fe69
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-nnbd-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/268762
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
for reference, the public link is: https://dart-review.googlesource.com/c/sdk/+/268762 |
|
Thanks, @sstrickl, great responsiveness as always! Now that the flutter engine rolled to the SDK with your change merged, I've checked the output. Looks pretty good, see the following stack trace from I'm wondering about a few things though:
|
|
|
@sstrickl do you think this issue (whatever is copying unrelated memory to the symbol path) could be in the Dart SDK or in Flutter? |
|
@sstrickl I think the issue with paths containing nonsense components has to do with obfuscation - when I disable it, the paths are resolved correctly. The test code that should cover this functionality doesn't do so with obfuscation enabled: 6730b12#diff-a1ba10025c42333799717c9da7b384e5d309691d5e5381a33f1e38a434abe1e6 BTW I've tried to dig into this and add it myself but I wasn't able to figure out how exactly to launch that specific test case, even after going through https://github.com/dart-lang/sdk/wiki/Testing 🤕 |
|
Looking into this starting today. First plan to change the My initial hypothesis looking at Ivan's example is that the deobfuscation code I've written in the DWARF subsystem is incorrectly substituting inside already-expanded parts of the string, e.g., in #44325 (comment), I imagine that |
|
Good news, everyone, changing the test to add |
|
... though looking at the code, that's a bit confusing, as we don't do an in-place deobfuscation, so there's no reason we'd be inspecting part of the expanded string, unless we're deobfuscating a string that was already deobfuscated, or attempting to deobfuscate one that was never obfuscated. Not sure which is happening, looking into that now. |
|
It's the latter, the compiler is attempting to deobfuscate a string that was not previously obfuscated. Looking at the obfuscation code, we never obfuscate the |
The DWARF generator would always attempt to deobfuscate the URL
retrieved from `Script` objects, whether it came from the `url`
or `resolved_url` field. However, the `resolved_url` field is not
obfuscated, and thus attempting to deobfuscate it could result in a different (and incorrect) string. Thus, only deobfuscate when not
resolving DWARF paths.
TEST=vm/dart{,_2}/use_resolve_dwarf_paths_flag
Bug: #44325
Change-Id: I57a3d47cc78035508082ccba23a2b1cd726ed6bb
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279086
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
|
Going ahead and closing this now that the CL fixing the deobfuscation issue has been landed, but do reopen if you find any other issues. |
|
I can confirm the fix works e2e in Flutter. Thanks again @sstrickl |
I'm reporting this here since I've seen symbolication being discussed in this issue tracker.
DWARF debugging information generated for Android builds contains logical file paths, either prefixed by
dart:orpackage:, followed by the package and finally the source path. For example, this is extracted usingdwarfdumpfrom an example app:This way of representing files makes sense to a developer, as it clearly states where the file belongs to and how it can be located. However, it is hard for a general-purpose debugger to locate these files, as it usually has no concept of "packages".
Usually, paths like the one referred to by
DW_AT_decl_fileare relative to a location called the "compilation directory". This is the location in which the compiler was invoked, and is often also considered the "project root". It is defined on the compilation unit, which in our case looks like this:It would be great to follow DWARF conventions and allow debuggers to locate source files by emitting absolute file paths. This would allow to step through code while debugging, and crash reporting tools like Sentry could attach source code to their crash reports. A possible approach to this would be:
DW_AT_comp_dirto the project's root folderdebug_infoanddebug_linesrelative to the compilation dir if they are in the directoryIt is still possible to retain custom paths by adding an extension to DWARF line programs after
DW_LNCT_MD5. Please let me know if I should elaborate on this point.The text was updated successfully, but these errors were encountered: