Hit MOZ_CRASH(resolving style on unstyled element) at servo/ports/geckolib/glue.rs:5426
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: sergeev917, Unassigned)
Details
Attachments
(5 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
Opened and navigated a web site with Firefox 83.0 on Linux.
Actual results:
A tab crash message was shown. No subsequent errors on tab reload.
Backtrace from the core dump shows:
Core was generated by `/usr/lib64/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 8738'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 MOZ_Crash (aReason=0x7ffd8013a45a "Resolving style on unstyled element", aLine=5426, aFilename=0x7ffd8013a662 "servo/ports/geckolib/glue.rs") at /var/tmp/portage/www-client/firefox-83.0/work/firefox_build/dis
t/include/mozilla/Assertions.h:254
254 /var/tmp/portage/www-client/firefox-83.0/work/firefox_build/dist/include/mozilla/Assertions.h: No such file or directory.
[Current thread is 1 (Thread 0x71b498499600 (LWP 3960))]
bt
#0 MOZ_Crash (aReason=0x7ffd8013a45a "Resolving style on unstyled element", aLine=5426, aFilename=0x7ffd8013a662 "servo/ports/geckolib/glue.rs") at /var/tmp/portage/www-client/firefox-83.0/work/firefox_build/dis
t/include/mozilla/Assertions.h:254
#1 RustMozCrash(char const*, int, char const*) (aFilename=0x7ffd8013a662 "servo/ports/geckolib/glue.rs", aLine=5426, aReason=0x7ffd8013a45a "Resolving style on unstyled element") at wrappers.cpp:17
#2 0x000071b493d0e00d in mozglue_static::panic_hook () at /usr/lib64/firefox/libxul.so
#3 0x766c6f7365520024 in ()
...
Expected results:
No tab crash should have happened.
Comment 1•4 years ago
|
||
Hi Alexander!
Please provide detailed steps or an example (url) in order to be able to reproduce the behaviour that you have reported.
Also, can you add the about:support data? (Help > troubleshooting information > click "copy raw data to clipboard" button).
Thanks!
Reporter | ||
Comment 2•4 years ago
|
||
Reporter | ||
Comment 3•4 years ago
|
||
Hi, Marcela!
Please provide detailed steps or an example (url) in order to be able to reproduce the behaviour that you have reported.
The crash has happened only once so far and on a banking page which requires users to log in. Also, there were no crashes after reloading the same page (but it's a PWA, so the page content is not particularly static).
Also, can you add the about:support data? (Help > troubleshooting information > click "copy raw data to clipboard" button).
The copied content is attached as about_support.json.
Comment 4•4 years ago
|
||
I was unable to reproduce this issue on latest Nightly version 86.0a1 (2020-12-16) (64 bit) on Ubuntu 20.04.
I will set a component to have a starting point from this. Please feel free to change it if you consider it is not the appropriate component.
Comment 5•4 years ago
•
|
||
Any chance you've reproduced this again?
If you're able to trigger it reliably, it would be great if you could trigger it within a Mozilla-provided Firefox build, which will then let you submit a crash report which would give us a bit more to go on here. (Linux-distro-provided Firefox packages typically have the crash reporter disabled, which limits our ability to investigate stuff like this.)
You could try downloading & using e.g. Firefox Developer Edition, which will use its own user profile (it can run separately alongside your existing Firefox, and maintains a separate set of bookmarks/history/addons etc.): https://www.mozilla.org/en-US/firefox/developer/
(Without a crash report or a testcase / live URL where we could reproduce this, we unfortunately may not have enough information to make progress here. The backtrace in comment 0 is definitely helpful but may not have enough stack levels / context to be useful.)
Reporter | ||
Comment 6•4 years ago
|
||
Any chance you've reproduced this again?
It's really rare (couple of times in months) and I cannot reliably reproduce it, at least currently.
By the way, is it possible to grab the actual page sources (the site is using client-side rendering) from devtools (opened in advance) after the crash happens? This would be useful for providing a proper reproducer.
If you're able to trigger it reliably, it would be great if you could trigger it within a Mozilla-provided Firefox build, which will then let you submit a crash report which would give us a bit more to go on here.
Okay, I will take this into account.
Reporter | ||
Comment 7•4 years ago
|
||
Reporter | ||
Comment 8•4 years ago
|
||
Hi! Today firefox had crashed again, the browser was rebuilt with more debug information preserved.
The backtrace in comment 0 is definitely helpful but may not have enough stack levels / context to be useful.
I'm attaching full backtrace on all threads.
Reporter | ||
Comment 9•4 years ago
|
||
The firefox version for the last backtrace is 85.0.
Comment 10•4 years ago
|
||
(In reply to Alexander Sergeyev from comment #6)
By the way, is it possible to grab the actual page sources (the site is using client-side rendering) from devtools (opened in advance) after the crash happens? This would be useful for providing a proper reproducer.
(No, I don't think it's currently possible to do that after the crash, unfortunately. The process that knows the page's DOM / styles / etc. is the same process that is crashing, and it can't be easily reasoned-with after it has crashed. Also, even if we were able to get a static snapshot of the page at that point, it's entirely likely that it'd render just fine; these sorts of crashes are usually caused by our internal mishandling of a particular change that is made to the page state.)
(In reply to Alexander Sergeyev from comment #8)
Hi! Today firefox had crashed again, the browser was rebuilt with more debug information preserved.
Thank you! emilio, can you make anything of the attached backtrace?
Comment 11•4 years ago
|
||
Not really, the backtrace looks perfectly normal unfortunately :(
Do you have any crash report from about:crashes maybe? Not too much, but that at least would allow us to discard some memory / binary issues.
Reporter | ||
Comment 12•4 years ago
|
||
Do you have any crash report from about:crashes maybe? Not too much, but that at least would allow us to discard some memory / binary issues.
No, it's not available (invalid url). Is there any particular piece of information you're interested in? Probably, I will be able to collect it without about:crashes.
Anyway, I'm going to update to 85.0.1 and try building it with debuginfo=2 to be able to poke with local variables in future coredumps.
Reporter | ||
Comment 13•4 years ago
|
||
Hello, everyone! I'm back with more details. Seems that the crash happens during a mouse event processing in a triggered svg rect item styling. I'm attaching the new stack trace and some relevant objects printouts. Please tell me if some other printouts are needed.
Reporter | ||
Comment 14•4 years ago
|
||
Reporter | ||
Comment 15•4 years ago
|
||
Hello! Probably, we could move a step forward with a patch to dump the problematic page source before crashing (stdout would do just fine)?
Comment 16•4 years ago
|
||
Yup, that's a great idea! Here's a patch that should do that on optimized builds.
Reporter | ||
Comment 17•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)
Yup, that's a great idea! Here's a patch that should do that on optimized builds.
Thank you! I've applied the patch with no problem. I'll come back when a crash happens again.
Reporter | ||
Comment 18•4 years ago
|
||
I've got a fresh crash. There is only one line dumped:
rect@0x7c7075e50c40 id="region.scaffold::icon:core/cards/mc36Mastercard::3" width="28" height="20" x="4" y="8" rx="2.5" state=[20800000] flags=[00000040] primaryframe=(nil) refcount=2<>
Is that useful enough?
Comment 19•4 years ago
|
||
Hmm, not particularly... Maybe we should print the whole DOM tree? It seems that's an SVG leaf.
Curious, was this an XML / XHTML document by any chance? A fuzzer just found a repro for a very similar issue which turned out to be a bug in the XML parser. SVG may use either the XML or HTML parser so it might be the same... Does applying https://phabricator.services.mozilla.com/D106421 make the bug go away for you?
Reporter | ||
Comment 20•4 years ago
|
||
Maybe we should print the whole DOM tree? It seems that's an SVG leaf.
Pretty sure this is a good idea. We can definitely tell a bug, but testing a patch is a probability game at this point (with no stable/conclusive repro). Though, sensitive data cleanup might be needed. Is it possible to reconstruct HTML input from a dumped DOM in a reasonable way?
Does applying https://phabricator.services.mozilla.com/D106421 make the bug go away for you?
Okay, I will try it out.
Reporter | ||
Comment 21•4 years ago
|
||
Is it possible to reconstruct HTML input from a dumped DOM in a reasonable way?
On second thought, I'm not totally convinced that a static HTML would do the trick, since the problem might be in transition between two states in reaction on some event (which is somewhat supported by the call stack). Would it be enough to have a full DOM to make a repro, or we're looking for a hint there?
Reporter | ||
Comment 22•4 years ago
|
||
Does applying https://phabricator.services.mozilla.com/D106421 make the bug go away for you?
It appears to make a difference. After sufficient time browsing the site no crashes have happened.
Reporter | ||
Comment 23•4 years ago
|
||
Just got a crash on a different web site (nextcloud instance) with the same underlaying error, but now coming from JIT in the stack trace. This is on firefox 86.0 with all previous patches applied (DOM printouts and FlushTags() in dom/xml/nsXMLContentSink.cpp), which previously seemed to work fine on the banking web site. I'll attach more info soon.
Reporter | ||
Comment 24•4 years ago
|
||
Reporter | ||
Comment 25•4 years ago
|
||
Comment 26•4 years ago
|
||
Curious, did you manage to reproduce this using an official build? How are your builds done? Those stacks all look perfectly normal so far and we don't have anything that ressembles that repro rate in crash-stats, so there has to be something about how you're building Firefox or such that's choking.
Is your compiler GCC or clang? Is there any interesting build options you're using?
Reporter | ||
Comment 27•4 years ago
|
||
Curious, did you manage to reproduce this using an official build?
Unfortunatelly, I didn't get my hands on it so far since it means a vm needs to be spooled and then some test load applied.
How are your builds done?
I'm using gentoo linux distribution and firefox is compiled from source as usual package install process.
Is your compiler GCC or clang?
Currently, it's gcc-10.2.0 and rust-1.50.0. Is clang being used in the official builds? I could try it as well (that is, clang-11.1.0).
Is there any interesting build options you're using?
Just -march=native -ggdb2 for c++ and similarly -C debuginfo=2 -C target-cpu=native for rustc. The target processor has (mobile) skylake arch.
Comment 28•4 years ago
|
||
Yes, official builds are done with clang (though fedora uses GCC).
Updated•3 years ago
|
Description
•