Treeherder summary failing to notice fatal plugin assertion

NEW
Unassigned

Status

Testing
General
2 years ago
2 years ago

People

(Reporter: mccr8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
In bug 1239258, a plugin is crashing with a fatal assertion that shows up in the log like this:

[NPAPI 4969] ###!!! ASSERTION: plug removed: 'glib assertion', file /builds/slave/m-in-l64-d-0000000000000000000/build/src/toolkit/xre/nsSigHandlers.cpp, line 140
#01: libglib-2.0.so.0 + 0x4ef61
#02: libglib-2.0.so.0 + 0x4f172
#03: libnptest.so + 0x53d4
#04: libgtk-x11-2.0.so.0 + 0x136dd8
#05: libgobject-2.0.so.0 + 0xfca2

The test harness is not detecting this, so it doesn't show up in the summary, which makes it so you have to look at the raw log to figure out what was actually failing.
There's sort of two issues here, right? One is that this assertion doesn't get highlighted in the log, and the other is that the harness doesn't notice the assertion and keeps soldiering on and only prints a failure at the very end when it's looking for leak logs.

For the former, I assume we don't generically highlight assertions because they're not fatal in most test suites, so we have a lot of expected assertions and they would clutter up the log if we did so. I don't know if there's something more sensible we could be doing there, obviously having to pore through the raw log looking for assertion stacks sucks.

For the latter, I guess the harness should be noticing unexpected content/plugin process crashes that don't result in minidumps? It's a bit distressing that we didn't generate a minidump here (that might be a separate issue), but this:
[Parent 4811] WARNING: [PluginModuleParent::ActorDestroy] abnormal shutdown without minidump!: file /builds/slave/m-in-l64-d-0000000000000000000/build/src/dom/plugins/ipc/PluginModuleParent.cpp, line 1592

really ought to at least generate a TEST-UNEXPECTED-FAILURE for the test currently being run in the general case.
(Reporter)

Comment 2

2 years ago
Ah, good point. I guess the relevant failure here is the missing minidump and not the assertion. I assume if there was a minidump we'd produce some kind of message about the crash in that test.
I filed bug 1239362 on that g_error not triggering Breakpad.
You need to log in before you can comment on or make changes to this bug.