1660965 - Report corrupted JS::Values in crash data

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task)

Description

[Jon Coppeard (:jonco)]

To help track down crashes like bug 1658070 we can report corrupted JS::Values that we encounter in the crash message. This could help to distinguish poison values, heap corruption, bad memory etc.

Comment 1

[Jon Coppeard (:jonco)]

Attachment: Bug 1660965 - Report bad JS::Value contents in crash messages r?jandem

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a8f04609cdd8
Report bad JS::Value contents in crash messages r=jandem

Comment 3

[Nicolas B. Pierron [:nbp]]

I think adding such MOZ_CRASH_UNSAFE_PRINTF requires a data-review as well, at least that's how I understood it the last time I added such statement in Bug 1405843.

See https://wiki.mozilla.org/Firefox/Data_Collection#Data_Collection_Categories and https://github.com/mozilla/data-review/blob/master/request.md

Comment 4

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/a8f04609cdd8

Comment 5

[Jon Coppeard (:jonco)]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)
Oh, I didn't realise that (similar data is already available publicly in crash-stats). I'll request a data-review.

Comment 6

[Jon Coppeard (:jonco)]

Attachment: data_collection_request.txt

After-the-fact data collection request.

Comment 7

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Comment on attachment 9172220 [details]
data_collection_request.txt

Thanks!

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes; this is a value rendered into the MozCrashReason annotation documented at https://searchfox.org/mozilla-central/rev/d54712b9644b49cec6cc90a9e0c325fdfab04e7c/toolkit/crashreporter/CrashAnnotations.yaml#646-651 and https://searchfox.org/mozilla-central/rev/d54712b9644b49cec6cc90a9e0c325fdfab04e7c/toolkit/components/telemetry/docs/data/crash-ping.rst#66.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out and declining to send a crash report.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, jonco.

4. 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.

5. Is the data collection request for default-on or default-off?

Default-on.

6. 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.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes.

8. Does there need to be a check-in in the future to determine whether to renew the data?

No.

9. Does the data collection use a third-party collection tool?

No.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Shall [@ js::ReportBadValueTypeAndCrash(JS::Value const&)] be the crash signature or should frame 0 get ignored for it? See this example.

Comment 9

[Jon Coppeard (:jonco)]

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #8)
We should ignore the first frame (although it's also interesting to look at stats for these crashes all together).