Closed
Bug 1512816
Opened 5 years ago
Closed 5 years ago
web-platform-test doesn't resolve symbols in assertion stacks in debug builds
Categories
(Testing :: web-platform-tests, defect)
Testing
web-platform-tests
Tracking
(firefox66 fixed)
RESOLVED
FIXED
mozilla66
Tracking | Status | |
---|---|---|
firefox66 | --- | fixed |
People
(Reporter: jya, Assigned: jgraham)
Details
Attachments
(1 file)
Example: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=216032322&repo=try&lineNumber=45230 which shows the crash stack as: 23:07:48 INFO - PID 2275 | Assertion failure: !IsExclusive || !mHaveRequest (Using an exclusive promise in a non-exclusive fashion), at /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/MozPromise.h:810 23:07:48 INFO - PID 2275 | #01: 2018-12-07 23:07:48.635 atos[2282:43485] Metadata.framework [Error]: couldn't get the client port 23:07:48 INFO - PID 2275 | #02: 0x0398d6ea (in XUL) + 74 23:07:48 INFO - PID 2275 | #03: 0x039768b9 (in XUL) + 665 23:07:48 INFO - PID 2275 | #04: 0x0397b02d (in XUL) + 1341 23:07:48 INFO - PID 2275 | #05: 0x0396d7dd (in XUL) + 1837 23:07:48 INFO - PID 2275 | #06: 0x0396cf4c (in XUL) + 1036 23:07:48 INFO - PID 2275 | #07: 0x0106311b (in XUL) + 571 23:07:48 INFO - PID 2275 | #08: 0x010611e9 (in XUL) + 1465 23:07:48 INFO - PID 2275 | #09: 0x01066d72 (in XUL) + 18 23:07:48 INFO - PID 2275 | #10: 0x00120f0e (in XUL) + 46 23:07:48 INFO - PID 2275 | #11: 0x0013bb5c (in XUL) + 2316 23:07:48 INFO - PID 2275 | #12: 0x00140128 (in XUL) + 56 23:07:48 INFO - PID 2275 | #13: 0x008248d3 (in XUL) + 323 23:07:48 INFO - PID 2275 | #14: 0x007c6595 (in XUL) + 85 23:07:48 INFO - PID 2275 | #15: 0x03b29179 (in XUL) + 41 23:07:48 INFO - PID 2275 | #16: 0x03b9f315 (in XUL) + 581 23:07:48 INFO - PID 2275 | #17: 0x055c4b05 (in XUL) + 341 23:07:48 INFO - PID 2275 | #18: 0x00825281 (in XUL) + 65 23:07:48 INFO - PID 2275 | #19: 0x007c6595 (in XUL) + 85 which isn't particularly useful.
Is this the same as bug 1512488 and bug 1510698?
Reporter | ||
Comment 2•5 years ago
|
||
The other bug is linux and the other does show some symbols. Here on mac I get nothing at all. so maybe they are the same, not sure
Comment 3•5 years ago
|
||
Treeherder displays the results/logs/... of jobs run via other systems (such as Taskcluster) mostly verbatim, so missing symbols will be due to an issue in a test harness/automation/... piece further upstream, rather than anything to do with Treeherder.
Component: Treeherder → General
Product: Tree Management → Firefox Build System
Version: --- → unspecified
Comment 4•5 years ago
|
||
This seems to be an issue with the web-platform-test harness invocation. If you look in the log you can see that mozharness downloads the symbols.zip: 22:13:03 INFO - Downloading and extracting to /Users/cltbld/tasks/task_1544244693/build/symbols these dirs * from https://queue.taskcluster.net/v1/task/RjgwHxTJRaWrSICM-lL2MA/artifacts/public/build/target.crashreporter-symbols.zip 22:13:03 INFO - retry: Calling fetch_url_into_memory with args: (), kwargs: {'url': 'https://queue.taskcluster.net/v1/task/RjgwHxTJRaWrSICM-lL2MA/artifacts/public/build/target.crashreporter-symbols.zip'}, attempt #1 22:13:03 INFO - Fetch https://queue.taskcluster.net/v1/task/RjgwHxTJRaWrSICM-lL2MA/artifacts/public/build/target.crashreporter-symbols.zip into memory 22:13:07 INFO - Content-Length response header: 152446392 22:13:07 INFO - Bytes received: 152446392 But then when the harness is invoked later it gets passed: --symbols-path=https://queue.taskcluster.net/v1/task/RjgwHxTJRaWrSICM-lL2MA/artifacts/public/build/target.crashreporter-symbols.zip ...instead of the on-disk path where the symbols were extracted. The wpt mozharness script seems to always pass the URL: https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/mozharness/scripts/web_platform_tests.py#223 whereas other harnesses will set `self.symbols_path` to the local on-disk path: https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/mozharness/mozharness/mozilla/testing/testbase.py#435 and `symbols_path` gets passed to the harnesses: https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/mozharness/scripts/desktop_unittest.py#388 https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/mozharness/configs/unittests/linux_unittest.py#90 wpt needs to do the same thing as other harnesses here. The wpt code works for handling crashes (because mozcrash will download the symbols on-demand) but for symbolicating assertion stacks in debug builds the symbols are needed up-front.
Assignee | ||
Comment 5•5 years ago
|
||
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=216596327&repo=try&lineNumber=29271 looks like this works with a patch to mozharness.
Assignee | ||
Comment 6•5 years ago
|
||
Updated•5 years ago
|
Summary: Mac debug log doesn't resolve symbols → web-platform-test doesn't resolve symbols in assertion stacks in debug builds
Pushed by james@hoppipolla.co.uk: https://hg.mozilla.org/integration/autoland/rev/2f2453dca7be Use on-disk symbols path for wpt when available, r=ted
Comment 8•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2f2453dca7be
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox66:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Updated•5 years ago
|
Assignee: nobody → james
You need to log in
before you can comment on or make changes to this bug.
Description
•