Closed
Bug 1351725
Opened 8 years ago
Closed 7 years ago
Crash in mozilla::gfx::GfxVarValue::AssertSanity
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox55 | --- | fix-optional |
People
(Reporter: calixte, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, Whiteboard: [clouseau],)
Crash Data
This bug was filed from the Socorro interface and is
report bp-e3b7620b-35eb-470f-86d0-db4222170329.
=============================================================
There are 7 crashes in nightly 55 with buildids 20170328095415 and 20170328030207. In analyzing the backtrace the regression may have been introduced by patch [1] to fix bug 1309200.
[1] https://hg.mozilla.org/mozilla-central/rev?node=60cb618034c4a249f9a1a37b3dee8281b851d597
Flags: needinfo?(nical.bugzilla)
Comment 1•8 years ago
|
||
There also seems to be one crash with Build ID 20170325030203, which is before the 28th.
Comment 2•8 years ago
|
||
From the back trace information, Gecko hits release assert in [1]. In [1], aType was set as TBackendType(1) and not expected to mType. Those updated GfxPrefValue in GfxVarUpdate was sent from GPUChild::Init() to build a list of prefs the GPU process will need. If parent side mismatch the index order by calling ApplyUpdate(), it might have chance to hit this crash.
From looked into bug 1309200, Maybe it would affect the order by adding a gfx var in [2]. I would take some time to see more.
[1]:https://searchfox.org/mozilla-central/source/__GENERATED__/ipc/ipdl/_ipdlheaders/mozilla/gfx/GraphicsMessages.h#959
[2]: https://searchfox.org/mozilla-central/rev/72fe012899a1b27d34838ab463ad1ae5b116d76b/gfx/config/gfxVars.h#28
Updated•8 years ago
|
Flags: needinfo?(milan)
Updated•8 years ago
|
Priority: -- → P1
Whiteboard: [clouseau] → [clouseau], [gfx-noted]
Updated•8 years ago
|
Priority: P1 → --
Whiteboard: [clouseau], [gfx-noted] → [clouseau],
How does ApplyUpdate change the index? There is a variable for each of these in gfxVars, and those should be initialized in the same order on all processes during gfxVars constructor. Can you elaborate?
Flags: needinfo?(milan)
I think you may have been saying that ApplyUpdate gets called before gfxVars is initialized in the first place. Perhaps it's the same root cause then as this in bug 1337062 comment 53.
Updated•8 years ago
|
Comment 5•8 years ago
|
||
I am not familiar with the internals of gfxVars and I would be very surprised if patch https://hg.mozilla.org/mozilla-central/rev?node=60cb618034c4a249f9a1a37b3dee8281b851d597 introduced an error since it mirrors exactly what the ContentBackend pref does in the same places.
Maybe David has better insights?
Flags: needinfo?(nical.bugzilla) → needinfo?(dvander)
Your patch definitely didn't cause this. It seems like another content/browser process mismatch thing, maybe. But there are no new reports in the past week.
Flags: needinfo?(dvander)
NI to check in a bit more and resolve if it's gone.
Flags: needinfo?(milan)
Seems to have gone away.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(milan)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•