Closed Bug 1631828 Opened 4 years ago Closed 11 months ago

Highlight "Mozilla crash reason"

Categories

(Tree Management :: Treeherder, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mccr8, Assigned: jmaher)

References

Details

Attachments

(1 file)

When you crash on a MOZ_RELEASE_ASSERT, there's this nice line in the log like this: Mozilla crash reason: MOZ_RELEASE_ASSERT(isWindowProxy)

It would be nice if it was highlighted. Bug 1608600 has ended up getting highlighted as "Uncaught exception - [Exception... "(null)" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "<unknown>" data: no]" which is not very useful.

Here's an example: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298565132&repo=autoland&lineNumber=5436

The specific situation here is that we're hitting a release assert in an opt build. In a debug build, you see the assertion failure.

For instance, bug 1625031 is the debug version of bug 1608600.

See Also: → 1608600
Component: Treeherder: Log Parsing & Classification → TreeHerder

I am looking into some options with highlighting asserts and crashes, and this bug showed up on my radar!

I see that we format this out here:
https://searchfox.org/mozilla-central/source/testing/mozbase/mozcrash/mozcrash/mozcrash.py#125

I am wondering what would be a good line to print out and highlight.

for a crash, given:

task 2023-03-28T10:41:41.654Z] 10:41:41     INFO - PROCESS-CRASH | /html/canvas/element/manual/wide-gamut-canvas/canvas-display-p3-drawImage-video.html | application crashed [@ libxul.so + 0x00000000062fb5fb]
[task 2023-03-28T10:41:41.654Z] 10:41:41     INFO - Mozilla crash reason: Caught GL error 500 at tex_storage_2d

we always highlight and parse the first line, would it be better to be:
task 2023-03-28T10:41:41.654Z] 10:41:41 INFO - PROCESS-CRASH | Caught GL error 500 at tex_storage_2d | /html/canvas/element/manual/wide-gamut-canvas/canvas-display-p3-drawImage-video.html | application crashed [@ libxul.so + 0x00000000062fb5fb]

for an assertion, given:

[task 2023-04-05T16:36:47.242Z] 16:36:47     INFO - GECKO(8712) | Assertion failure: (((HRESULT)(hr)) >= 0), at /builds/worker/checkouts/gecko/accessible/windows/msaa/MsaaAccessible.cpp:597
...
[task 2023-04-05T16:37:09.664Z] 16:37:09    ERROR - TEST-UNEXPECTED-FAIL | accessible/tests/browser/e10s/browser_caching_name.js | application terminated with exit code 1
[task 2023-04-05T16:37:20.065Z] 16:37:20     INFO - PROCESS-CRASH | accessible/tests/browser/e10s/browser_caching_name.js | application crashed [@ mozilla::a11y::MsaaAccessible::GetIAccessibleFor]
[task 2023-04-05T16:37:20.065Z] 16:37:20     INFO - Mozilla crash reason: MOZ_ASSERT((((HRESULT)(hr)) >= 0))

we would instead see:

[task 2023-04-05T16:36:47.242Z] 16:36:47     INFO - GECKO(8712) | Assertion failure: (((HRESULT)(hr)) >= 0), at /builds/worker/checkouts/gecko/accessible/windows/msaa/MsaaAccessible.cpp:597
...
[task 2023-04-05T16:37:20.065Z] 16:37:20     INFO - PROCESS-CRASH | MOZ_ASSERT((((HRESULT)(hr)) >= 0)) | accessible/tests/browser/e10s/browser_caching_name.js | application crashed [@ mozilla::a11y::MsaaAccessible::GetIAccessibleFor]

I could always just highlight the mozilla crash reason, but I would rather print out something useful, so we don't have a cascading set of failures.

:mccr8, do you have thoughts on this (I know you filed this bug a long time ago)

Flags: needinfo?(continuation)

Looks reasonable to me. I don't have any more specific thoughts.

Flags: needinfo?(continuation)
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/08b45202b9c7
use mozilla reason when we have a crash, and track by crash, not test. r=ahal
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4715858296dd
use mozilla reason when we have a crash, and track by crash, not test. r=ahal
Flags: needinfo?(jmaher)
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Regressions: 1862116
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: