Closed
Bug 1331253
Opened 9 years ago
Closed 9 years ago
Crash in nsDisplayBoxShadowOuter::ComputeVisibility
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| firefox51 | + | wontfix |
| firefox52 | --- | unaffected |
People
(Reporter: marcia, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is
report bp-9d853a79-4af5-4e13-a1e6-b657d2170115.
=============================================================
New crash seen in B14 with AMD drivers: http://bit.ly/2iqkDYo. This particular crash was not present in the earlier betas.
For some reason tracking flags are greyed out for me in the UI, so I will try to set those later.
| Reporter | ||
Comment 1•9 years ago
|
||
[Tracking Requested - why for this release]: Maybe makes sense to track this since it is a new signature that started in B14.
status-firefox51:
--- → affected
tracking-firefox51:
--- → ?
Comment 2•9 years ago
|
||
those crashes are all coming from our usual problematic "AuthenticAMD family 20 model 2" cpu models, so it may just be a fluke that goes away again in the next build.
Comment 3•9 years ago
|
||
We should be heading to an RC2 build this week, so let's make sure to check back after that.
But I'd like someone to look as soon as possible since it could just as easily be a regression in beta 14.
Jet or Milan, can you help find someone who can investigate today?
Daniel, can you tell from the stack? Nothing in https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX_51_0b13_RELEASE&tochange=FIREFOX_51_0b14_RELEASE jumps out, but I'm not sure I know what to look for in the layout code. Perhaps one of the actual content changes (bug 1330303, bug 1330611) exposed an old, existing bug?
Flags: needinfo?(milan) → needinfo?(dholbert)
Comment 5•9 years ago
|
||
The stack in Comment 0's crash report looks bogus - JS calling directly into this nsDisplayBoxShadow code.
I don't think there's any way for that call to actually happen, so I don't think we cab trust the stack here.
Flags: needinfo?(dholbert)
Comment 6•9 years ago
|
||
My guess is that we need to take a look at an actual minidump to diagnose what's going wrong here. I don't have any experience with that, so I'm probably not the best person to dive in.
Having said that, comment 2 makes me wonder if this crash was already happening on this hardware before, and the (bogus) signature just changed in this build...
| Reporter | ||
Comment 7•9 years ago
|
||
I only see crashes in 51.0b14 so far, none yet in the RC.
Updated•9 years ago
|
Flags: needinfo?(bugs)
Comment 8•9 years ago
|
||
Mark 51 won't fix as 51 was released and I don't see any crashes recently.
Comment 9•9 years ago
|
||
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) in Firefox (except some obsolete Fx <52, no crashes starting since Fx 52).
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox52:
--- → unaffected
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•