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)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

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

People

(Reporter: Usul, Unassigned)

References

(Blocks 1 open bug,
URL
)

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.
Blocks: stylo-site-issues
status-firefox56: --- → affected
tracking-firefox56: --- → ?
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.
tracking-firefox56: ? → +
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.