Wayland protocol errors are not handled by the crash reporter
Categories
(Core :: Graphics, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox93 | --- | fixed |
People
(Reporter: rmader, Assigned: rmader)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/plain
|
travis_
:
data-review+
|
Details |
This has been a know issue for some time: whenever we crash because of a protocol error (which is always a bug on our side), the crash will not be handled and reported. In order to be sure we get crash reports for such bugs, investigate how we can propagate such errors.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
It looks like we can use wl_log_set_handler_client()
and crash there. There are a few exceptions where wl_log
is called without resulting in an abort, but apparently that's only wl_proxy_add_listener()
and wl_proxy_add_dispatcher()
- both should be easy to handle. This is also how what Xwayland does, see https://gitlab.freedesktop.org/wayland/wayland/-/issues/231#note_1044026
Assignee | ||
Comment 2•3 years ago
|
||
To ensure Wayland protocol errors trigger crash reports.
This is inspired by Xwayland, which handles things similarly.
Note: in theory there are a few cases we wouldn't need to crash on
wl_log
- but in practice we always want to.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
MOZ_CRASH_UNSAFE(explanation-string) can be used if the explanation string
cannot be a string literal
MOZ_CRASH_UNSAFE_PRINTF(format, arg1 [, args]) can be used when more
information is desired than a string literal can supply.
Comment 4•3 years ago
|
||
Would it even be safe (privacy-wise) to include more precise protocol error information? All crash reasons are public on crash-stats.mozilla.org. I assume that's why they're called unsafe.
Assignee | ||
Comment 5•3 years ago
|
||
(In reply to Darkspirit from comment #4)
Would it even be safe (privacy-wise) to include more precise protocol error information? All crash reasons are public on crash-stats.mozilla.org. I assume that's why they're called unsafe.
Protocol errors, as far as I know, are usually static strings from libwayland
or the the compositor. The only non-static data I've seen so far are surface ids and similar stuff. If there was ever privacy sensitive data in them, I'd consider that a compositor bug.
Given that it's quite common to ask for WAYLAND_DEBUG
logs in public issue reports and I've never seen any private related info, I think we can do this.
Assignee | ||
Comment 6•3 years ago
|
||
Here's a try build that, with gfx.webrender.compositor.force-enabled
turned on, crashes after a bit of scrolling and thus demonstrates that indeed the crash reporter shows up with the appropriate crash reason.
https://treeherder.mozilla.org/jobs?repo=try&revision=5174b081e9445877799921da2e9a414947cbf7a4
Assignee | ||
Comment 7•3 years ago
|
||
This reverts D123286 as we now have a generic way to trigger crash
reports on Wayland protocol errors.
Depends on D123894
Assignee | ||
Comment 8•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Comment on attachment 9238692 [details]
Wayland protocol error message collection request
:rmader
Can you please provide answers for items 11 (where you intend to share the results) and 12 (are you using a third-party tool for analysis)?
Also, for permanent collections, an individual contributor must be responsible for monitoring the collection, you can still reference the team as a fallback.
Thanks!
Assignee | ||
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
Updated version.
Comment 12•3 years ago
|
||
Comment on attachment 9238706 [details]
Wayland protocol error message collection request
Data Review
- Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
Yes
- Is there a control mechanism that allows the user to turn the data collection on and off?
Yes, by not sending the crash report
- If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, Robert Mader (robert.mader@posteo.de) / Linux dev team will monitor this collection.
- Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical data
- Is the data collection request for default-on or default-off?
default-off, user must send the crash report for collection to occur
- Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?
No
- Is the data collection covered by the existing Firefox privacy notice?
Yes
- Does the data collection use a third-party collection tool?
No
Result
data-review+
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/875255176657
https://hg.mozilla.org/mozilla-central/rev/b2c5ed1aea75
Description
•