Closed Bug 1317627 Opened 8 years ago Closed 7 years ago

Crashes in nsIContent::GetPrimaryFrame with garbage pointer address and EXCEPTION_ACCESS_VIOLATION_READ

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
52 Branch
Platform:
Unspecified
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1326194
Tracking Flags:
Tracking Status
firefox-esr45 --- affected
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- disabled
firefox53 + fixed

People

(Reporter: ting, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-bd74aefc-b280-4abe-9ed5-fa6be2161114.
=============================================================
#19 top crash on Windows for Nightly 52.0a1 20161113030203, 7 crashes from 5 installations. The first observation was from build 20161031030202.
Priority: -- → P3
#13 topcrash in Nightly 20161230030205. dbaron, do you know about this code?
Flags: needinfo?(dbaron)
There are at least three different stacks. One goes through a11y code, one goes through intersection observer, and one just the code in nsRefreshDriver.
Looks like it started in nightlies from 20161228, which implies the regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3119a9a0b5dee60ac77b7596ae5dbe0658f598ad&tochange=d7b6af32811bddcec10a47d24bd455a1ec1836fc

Many of the stacks appear slightly corrupted in crash-stats (although maybe the MSVC debugger would show better results).  One that doesn't is bp-4990e455-a53c-40c4-beb7-35bdb2170102, which seems to implicate IntersectionObserver.

Given that bug 1321865 is in the regression window, I think that's a pretty decent guess.

[Tracking Requested - why for this release]: nightly topcrash
Blocks: 1321865
status-firefox52: --- → unaffected
status-firefox53: --- → affected
tracking-firefox53: --- → ?
Flags: needinfo?(dbaron) → needinfo?(tschneider)
Keywords: topcrash
Summary: Crash in nsIContent::GetPrimaryFrame → Crashs in nsIContent::GetPrimaryFrame with garbage pointer address and EXCEPTION_ACCESS_VIOLATION_READ
Summary: Crashs in nsIContent::GetPrimaryFrame with garbage pointer address and EXCEPTION_ACCESS_VIOLATION_READ → Crashes in nsIContent::GetPrimaryFrame with garbage pointer address and EXCEPTION_ACCESS_VIOLATION_READ
Tracking 53+ for this nightly top crash.
tracking-firefox53: ? → +
Crash volume for signature 'nsIContent::GetPrimaryFrame':
 - nightly (version 53): 70 crashes from 2016-11-14.
 - aurora  (version 52): 3 crashes from 2016-11-14.
 - beta    (version 51): 76 crashes from 2016-11-14.
 - release (version 50): 1062 crashes from 2016-11-01.
 - esr     (version 45): 154 crashes from 2016-07-06.

Crash volume on the last weeks (Week N is from 01-02 to 01-08):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly      38       0       0       1       0       7       8
 - aurora        1       0       0       1       0       1       0
 - beta          9      13      13       6       6      16       9
 - release     124     162     187     199     185     125      33
 - esr           2       3      12      10      18       7       7

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly           #73
 - aurora            #1019
 - beta    #1000     #2504
 - release #342      #3510
 - esr     #1104
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: unaffected → affected
status-firefox-esr45: --- → affected
Crash caused by dangling pointers left in mObservationTargets.
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox52: unaffected → affected
Flags: needinfo?(tschneider)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.