Closed Bug 1381475 Opened 7 years ago Closed 7 years ago

Stylo: Crash in mozalloc_abort | abort | geckoservo::glue::Servo_ResolveStyle

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 + fixed

People

(Reporter: Usul, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: crash, reproducible, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-4c1c5a17-9b44-41ca-ae21-ac0840170717.
=============================================================
0 	firefox 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:33
1 	firefox 	abort 	memory/mozalloc/mozalloc_abort.cpp:80
2 	libxul.so 	std::panicking::rust_panic 	libpanic_abort/lib.rs:61
3 	libxul.so 	std::panicking::rust_panic_with_hook 	libstd/panicking.rs:565
4 	libxul.so 	std::panicking::begin_panic<&str> 	libstd/panicking.rs:511
5 	libxul.so 	geckoservo::glue::Servo_ResolveStyle 	servo/ports/geckolib/glue.rs:2783
6 	libxul.so 	mozilla::ServoStyleSet::ResolveServoStyle 	layout/style/ServoStyleSet.cpp:1177
7 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:553
8 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
9 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
10 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
11 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
12 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
13 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
14 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
15 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
16 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
17 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
18 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
19 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
20 	libxul.so 	mozilla::ServoRestyleManager::ProcessPostTraversal 	layout/base/ServoRestyleManager.cpp:633
21 	libxul.so 	mozilla::ServoRestyleManager::DoProcessPendingRestyles 	layout/base/ServoRestyleManager.cpp:827
22 	libxul.so 	libxul.so@0x1e35a06 	
23 	libxul.so 	mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) 	
24 	libxul.so 	nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) 	
25 	libxul.so 	nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) 	
26 	libxul.so 	mozilla::widget::PuppetWidget::DispatchEvent 	widget/PuppetWidget.cpp:368
27 	libxul.so 	mozilla::layers::APZCCallbackHelper::DispatchWidgetEvent 	gfx/layers/apz/util/APZCCallbackHelper.cpp:492
28 	libxul.so 	mozilla::dom::TabChild::RecvRealMouseButtonEvent 	dom/ipc/TabChild.cpp:1586
29 	libxul.so 	mozilla::dom::TabChild::RecvSynthMouseMoveEvent 	dom/ipc/TabChild.cpp:1550
30 	libxul.so 	mozilla::dom::PBrowserChild::OnMessageReceived 	obj-firefox/ipc/ipdl/PBrowserChild.cpp:3484
31 	libxul.so 	mozilla::dom::PContentChild::OnMessageReceived 	obj-firefox/ipc/ipdl/PContentChild.cpp:5296
32 	libxul.so 	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 	
33 	libxul.so 	libxul.so@0xc6022b 	
34 	libxul.so 	mozilla::ipc::MessageChannel::MessageTask::Run() 	
35 	libxul.so 	mozilla::SchedulerGroup::Runnable::Run 	xpcom/threads/SchedulerGroup.cpp:367
36 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	
37 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	
38 	libxul.so 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	
39 	libxul.so 	MessageLoop::Run() 	
40 	libxul.so 	nsBaseAppShell::Run 	widget/nsBaseAppShell.cpp:156
41 	libxul.so 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp:895
42 	libxul.so 	MessageLoop::Run() 	
43 	libxul.so 	XRE_InitChildProcess 	toolkit/xre/nsEmbedFunctions.cpp:711
44 	firefox 	content_process_main 	ipc/contentproc/plugin-container.cpp:64
45 	firefox 	_init 	
Ø 46 	libc-2.25.so 	libc-2.25.so@0x204d9 	
47 	firefox 	firefox@0x1116f 	
48 	firefox 	firefox@0x1a08f 	
49 	firefox 	firefox@0x1116f 	
50 	firefox 	mozilla::ReadAheadLib(char const*) 	
Ø 51 	ld-2.25.so 	ld-2.25.so@0x112cf 	
52 	firefox 	firefox@0x1a08f 	
53 	firefox 	_start


I was browsing a group on FB
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0 ID:20170717100221 CSet: aff336ac161daa3ea350e59a288963edbd58ed39

[Tracking Requested - why for this release]:
I hit the same crash right now by submitting a review comment to mozreview. Here the crash report: bp-d6e14430-fdcf-41c3-9cda-1d9180170717.
OS: Linux → All
Hardware: Unspecified → All
Btw this crash is happening kinda frequently for me. Mostly each 2nd or 3rd time I save a review comment the crash happens.
STR (with Stylo enabled):

(1) Load https://www.kruidvat.nl/kruidvat-16gb-3.0-usb-stick/p/3917159
(2) If it doesn't crash immediately, click on one of the thumbnails on the left side and keep clicking rapidly until it crashes.

I can get it to crash reliably within 10 seconds or so.
loading linkedin crashes it too.

Marcia is topcrash still a used keyword ?
(In reply to Ludovic Hirlimann [:Usul] from comment #5)
> loading linkedin crashes it too.
> 
> Marcia is topcrash still a used keyword ?

Yes, usually reserved for high volume crashes in the top 10 or so.
Adding a few Windows signatures.
Crash Signature: [@ mozalloc_abort | abort | geckoservo::glue::Servo_ResolveStyle] → [@ mozalloc_abort | abort | geckoservo::glue::Servo_ResolveStyle] [@ geckoservo::glue::Servo_ResolveStyle] [@ alloc::oom::default_oom_handler | geckoservo::glue::Servo_ResolveStyle]
Keywords: reproducible
71 crashes now -- and actually I got it 5 or 6 times already since I upgraded to latest Nightly 2 hours ago.
I was able to get this crash pretty reliably by visiting https://reviewboard.mozilla.org/r/153286/ when it was in its "Submitted" state (I had to disable Stylo to re-open it).
(In reply to Julien Wajsberg [:julienw] from comment #9)
> 71 crashes now -- and actually I got it 5 or 6 times already since I
> upgraded to latest Nightly 2 hours ago.

Similar frequency for me as well.
This tab crash is popping up for me on google docs today's nightly OSX. Is it possible this is related to bug 1379218? I can reproduce this very easily on gdocs by mousing over the user icons that are also viewing the doc repeatedly (about 20 times). As it's so similar to the issue in 1379218, maybe they are both related and have something to do with tooltips or hover states?
To folks hitting this crash:

The story here is that we've been seeing intermittent issues and low-volume crashes due to abnormal conditions that shouldn't occur. So over the weekend, emilio landed a change in bug 1380789 to release-assert against these conditions to make them easier to track down.

So the good news here is that it worked. The bad news is that it's made your stylo experience less stable, which I apologize for. We'll try to get it sorted out ASAP.

It's possible that there are several issues at play here, so please continue posting STR here if you find new ways to reproduce this panic.
STR: I hit this panic every time I switch channels in Slack.
(In reply to Chris Peterson [:cpeterson] from comment #14)
> STR: I hit this panic every time I switch channels in Slack.

I guess this is one of the STR I experienced, but I saw that on other tabs than Slack as well.
I also hit it consistently when switching Slack channels (maybe not every time, but often). I also reproduced it switching irccloud channels.
Another STR: Scrolling on facebook feed
Looking at various crash reports more closely, it seems that the assertion that most people are tripping is the less dire one (the styles might be out of date) rather than the more dire one (we forgot to style the element entirely).

Given that, I'm going to make that assertion non-fatal to avoid inflicting this level of crashiness on our testing population: https://github.com/servo/servo/pull/17757
> Looking at various crash reports more closely, it seems that the assertion that most people are tripping is the less dire one (the styles might be out of date) rather than the more dire one (we forgot to style the element entirely).

Given that stylo is opt-in and available only in nighlty. Isn't it better to track (possible multiple) issues under this one assert and fixing them one by one? Instead reintroducing few other crashes that were appearing randomly before including this assert?
(In reply to Kacper Michajłow [:kasper93] from comment #21)
> > Looking at various crash reports more closely, it seems that the assertion that most people are tripping is the less dire one (the styles might be out of date) rather than the more dire one (we forgot to style the element entirely).
> 
> Given that stylo is opt-in and available only in nighlty. Isn't it better to
> track (possible multiple) issues under this one assert and fixing them one
> by one? Instead reintroducing few other crashes that were appearing randomly
> before including this assert?

There's certainly an argument to make there (and it's the one I was making this morning), but I believe the second assertion (which is the one people are tripping) is less likely to indicate crashes than the first assertion. We have various STR in this bug, so I think it's safe to investigate it offline for the time being, and let our testers focus on finding other bugs.

(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #19)
> https://github.com/servo/servo/pull/17757

https://hg.mozilla.org/integration/autoland/rev/5c928291e2d5
I looked recent several reports, all of them were caused by flushing throttled animations, that means will be fixed by bug 1378064.  The assertion has been degraded [1] though.

[1] https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=5c928291e2d5051284d8858486d054b4c524bd18
Priority: -- → P1
Per comment 24.
Depends on: 1378064
Track 56+ as this is a spike crash today.
The signature 'geckoservo::glue::Servo_ResolveStyle' is ranked #5 in content topcrashes for nightly 56.
Keywords: topcrash
I can repro about once in every 5-10 pageloads of https://zapier.com/
I hit this https://crash-stats.mozilla.com/report/index/c9984fa6-6023-42ba-84f9-d32e00170718
when sso.mozilla.org was trying to render an animation to offer me my one mozilla account to use to login. I had to turn stylo off to be able to login, because it kept crashing when restoring the tab.
I hit this while attempting to navigate the start page of last.fm with the NVDA screen reader. bp-4f874fad-3c26-4cae-b214-160a90170718
Note that the assertion which causes this crash has been already degraded in https://hg.mozilla.org/integration/autoland/rev/5c928291e2d5051284d8858486d054b4c524bd18 . This crash will not happen once the commit gets merged in m-c and release a nightly which includes the commit.
Thanks for the patience.
The fix didn't make it into the latest Nightly, but we're respinning to get it in. NI RyanVM (who I believe was the point of contact on this) to confirm when it's done.
Flags: needinfo?(ryanvm)
Respins are finished and available across all platforms. If about:buildconfig says you're on revision dece50457378ac4934afe9fb3c2a8054e8894588, you've got the right one.
Flags: needinfo?(ryanvm)
I'm on inbound with this patch.  With Stylo enabled I am crashing at just about every site I go to.  I even crash on Fx startup.  With Stylo disabled all is well.  Running on Windows 10 64 bit Pro.
I can't find this bug number on inbound but I found #17757 for Stylo which I have on my Fx.  Is this what is supposed to fix the crashes?
yes, could you please upload the backtrace at crash somewhere?
If you're running a local build of inbound, try running the latest nightly instead?
Running Nightly 64 bit and I'm getting the same crashes as Inbound which is all the time.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #35)
> Respins are finished and available across all platforms. If
> about:buildconfig says you're on revision
> dece50457378ac4934afe9fb3c2a8054e8894588, you've got the right one.

I updated to the latest nightly on OS X and now I'm on 5e73b9798464c3f7106f0161dc9a49b234f42f9c which is not the revision you mentioned. And I get no fresher nightly when I do an update check:

https://aus5.mozilla.org/update/6/Firefox/56.0a1/20170718100333/Darwin_x86_64-gcc3/en-US/nightly/Darwin%2016.6.0/NA,16384/default/default/update.xml?force=1

Nick, do we currently have problems updating users on Nightly to 5e73b9798464c3f7106f0161dc9a49b234f42f9c? As it looks like all the partial updates have been created through:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=dece50457378ac4934afe9fb3c2a8054e8894588&filter-searchStr=update&filter-tier=1&filter-tier=2&filter-tier=3
Flags: needinfo?(nthomas)
We froze updates in bug 1382043 until the startup crash is resolved.
Flags: needinfo?(nthomas)
Hit this by toggling YouTube video's gear icon (the menu for speed and resolution) multiple times. https://crash-stats.mozilla.com/report/index/98e02ba5-91f3-4c94-bcc2-101810170719#tab-details
Depends on: 1382357
Crash Signature: [@ mozalloc_abort | abort | geckoservo::glue::Servo_ResolveStyle] [@ geckoservo::glue::Servo_ResolveStyle] [@ alloc::oom::default_oom_handler | geckoservo::glue::Servo_ResolveStyle] → [@ mozalloc_abort | abort | geckoservo::glue::Servo_ResolveStyle] [@ geckoservo::glue::Servo_ResolveStyle] [@ alloc::oom::default_oom_handler | geckoservo::glue::Servo_ResolveStyle] [@ mozalloc_abort | abort | core::option::expect_failed | geckoservo::…
The original case has not happened since Bobby's commit https://hg.mozilla.org/mozilla-central/rev/5c928291e2d5 . And the cause has been fixed by bug 1381431 (formerly bug 1378064).
We are still suffering from the crash in Servo_ResolveStyle, but it's tracked in bug 1382568.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I get a crash with the same signature. Reopen or file a new bug?
URL is http://web.security.plumbing/hackability
Maybe make it part of bug 1382568 and comment there. As best also add the link to the crash report.
You need to log in before you can comment on or make changes to this bug.