Closed Bug 1559699 Opened 5 years ago Closed 5 years ago

Crash in [@ nsDisplayHitTestInfoItem::~nsDisplayHitTestInfoItem]

Categories

(Core :: Web Painting, defect, P3)

68 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox67 --- unaffected
firefox68 --- wontfix
firefox69 --- unaffected
firefox70 --- unaffected

People

(Reporter: philipp, Unassigned)

References

(Regression)

Details

(5 keywords)

Crash Data

This bug is for crash report bp-43e6331b-4c21-4456-9aeb-1bb4d0190610.

Top 10 frames of crashing thread:

0 xul.dll nsDisplayHitTestInfoItem::~nsDisplayHitTestInfoItem layout/painting/nsDisplayList.h:3800
1 xul.dll static void nsDisplayCompositorHitTestInfo::~nsDisplayCompositorHitTestInfo layout/painting/nsDisplayList.h:5207
2 xul.dll nsDisplayItemBase::Destroy layout/painting/nsDisplayList.h:2158
3 xul.dll RetainedDisplayList::DeleteAll layout/painting/nsDisplayList.h:3762
4 xul.dll void nsDisplayContainer::Destroy layout/painting/nsDisplayList.h:3880
5 xul.dll RetainedDisplayList::DeleteAll layout/painting/nsDisplayList.h:3762
6 xul.dll void nsDisplayContainer::Destroy layout/painting/nsDisplayList.h:3880
7 xul.dll RetainedDisplayList::DeleteAll layout/painting/nsDisplayList.h:3762
8 xul.dll void nsDisplayContainer::Destroy layout/painting/nsDisplayList.h:3880
9 xul.dll RetainedDisplayList::DeleteAll layout/painting/nsDisplayList.h:3762

this crash signature is newly showing up cross-platform starting in firefox 68 - it's a low volume crash though.

The priority flag is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(matt.woodrow)
Priority: -- → P3

Miko could you take a look to see if this reproducible?

Flags: needinfo?(mikokm)

(In reply to Jessie [:jbonisteel] plz needinfo from comment #2)

Miko could you take a look to see if this reproducible?

This looks like it might have gone away, since we do not have any reports for 69.

A lot of the reports (roughly half) seem to be from one person. Matt suggested this might have been caused by a corrupt binary.

Flags: needinfo?(mikokm)

dveditz - I am not sure what the protocol for this bug is, since it looks like it has gone away. Should we leave it open for now?

Flags: needinfo?(dveditz)

(In reply to Miko Mynttinen [:miko] from comment #3)

A lot of the reports (roughly half) seem to be from one person. Matt suggested this might have been caused by a corrupt binary.

In crashes from the past two weeks all the installs appeared to be unique except one person who crashed twice. That many people with a corrupt binary crashing in this specific way?

I'm worried that there are a few that look like UAF signatures, but a bunch that aren't. Is it a UAF but most of the time the memory has been reallocated? Scary. Is it a wildptr, and sometimes it just happens to point at freed memory and pick up the pattern?

(In reply to Jessie [:jbonisteel] plz needinfo from comment #4)

dveditz - I am not sure what the protocol for this bug is, since it looks like it has gone away. Should we leave it open for now?

If the affected release weren't an ESR we'd normally call it "worksforme" and move on for this volume of crashes. But Firefox 68 is an ESR and that complicates things. On the other hand I'm only seeing one ESR crash in the past 3 months though (out of 222 with this signature) and there's no clear way forward with this bug. It may not be worth hunting down.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WORKSFORME

The ESR68 population is probably quite small still, and will only pick up after 68.2. This crash was low volume to start with, so I wouldn't expect many crashes from the ESR yet.

Group: gfx-core-security → core-security-release
Group: core-security-release
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.