1455366 - Crash in style::gecko::data::PerDocumentStyleData::new

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P2)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-4515185d-62a8-47a1-a5a2-3af4b0180417.
=============================================================

Top 10 frames of crashing thread:

0  @0x1af7f010 
1 xul.dll style::gecko::data::PerDocumentStyleData::new servo/components/style/gecko/data.rs:124
2 xul.dll geckoservo::glue::Servo_StyleSet_Init servo/ports/geckolib/glue.rs:2593
3 xul.dll mozilla::ServoStyleSet::Init layout/style/ServoStyleSet.cpp:137
4 xul.dll mozilla::PresShell::Init layout/base/PresShell.cpp:956
5 xul.dll nsDocument::CreateShell dom/base/nsDocument.cpp:3943
6 xul.dll nsDocumentViewer::InitPresentationStuff layout/base/nsDocumentViewer.cpp:691
7 xul.dll nsDocumentViewer::InitInternal layout/base/nsDocumentViewer.cpp:946
8 xul.dll nsDocumentViewer::Init layout/base/nsDocumentViewer.cpp:666
9 xul.dll nsDocShell::SetupNewViewer docshell/base/nsDocShell.cpp:9114

=============================================================

this crash signature is appearing on windows in firefox 57 and upwards.

Comment 1

[Andrew McCreight [:mccr8]]

Any ideas, Emilio?

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Huh, not really... The stacks there make sense afaict, and the code in there is somewhat simple. Maybe a garbage pres-context pointer?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

But we call a method on prescontext before the servo stuff. I would have expected a crash there if prescontext is dead.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Right, generally speaking at that point should be fresh. We basically just created it and called AttachShell on it to tie it to the pres shell...

I'm not aware of anything around there that could make it dead. We also access the nsIDocument pointer (to get the compat mode), but it's not clear to me how it could be dead either.

Comment 5

[Mats Palmgren (inactive)]

Fwiw, many (but not all) of these are startup crashes, e.g.
bp-ce79204a-2d6d-4834-8af8-7d8d50180419

Comment 6

[Cameron McCormack (:heycam)]

Attachment: chkimg log

I grabbed all the crashes from the last 3 months (there were 18 of them) and ran them through chkimg.  All except one exhibited mismatches around the crashing instruction.  The one that didn't (191afda0-d2a1-4b64-b97d-9c8330180828) had jumped off to some random place, and so it's possible that there was some corruption in the stack frame above that wasn't captured in the minidump (since only bytes around the IP at the time of the crash are captured).

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

So if all the crashes in 3 months show instructions being trashed, that would tend to point to making this invalid, since the codespace shouldn't be writable.  Seems oddly high, but not impossible.  It'd be amusing to run a study of validating all code and comparing errors/time running (though rarely-used code might be paged out/in or dropped (reload from executable when needed), so that could skew the results).  Also compare to the number of corruptions found in reports (have automated processing flag corrupted dumps)

If we think there might be some real crashes hiding here, we could mark it stalled (and maybe sec-other it) until we find a real crash we can look at with this signature

Comment 8

[Cameron McCormack (:heycam)]

(In reply to Randell Jesup [:jesup] from comment #7)
> Also compare to the number
> of corruptions found in reports (have automated processing flag corrupted
> dumps)

Hopefully automated processing will come soon (in bug 1274628, which you've seen).

> If we think there might be some real crashes hiding here, we could mark it
> stalled (and maybe sec-other it) until we find a real crash we can look at
> with this signature

I don't think this at the moment.  I'm inclined to just close the bug.