Open Bug 1751538 Opened 2 years ago Updated 2 years ago

Firefox crashes when writing a post on blogger.com

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
Firefox 96
Platform:
x86
Windows 7
Type:
defect

Tracking

()

People

(Reporter: seko.idiootti, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

with a default profile this happens.png
95.27 KB, image/png
Details

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

After updating to 96.0.2, it's impossible to write a post on blogger.com without Firefox crashing. Every time within an hour at the most, usually sooner, when writing a post on blogger.com, Firefox will suddenly crash. Thankfully it hasn't started crashing in any other context (at least so far), but it happened five or six times when I was trying to write a blog post. I even tried writing a different post just to see if maybe something in that particular post was causing it, but no, just five minutes into writing a new post with no stylisation or anything, Firefox crashed.

I'm not entirely sure if this would've happened already a little earlier because the last time I wrote a blog post was on December 22, but it happens now.

Might be important to mention that I used to have a lot of crashes and other problems because of webrender (see https://bugzilla.mozilla.org/show_bug.cgi?id=1729779), which could be prevented with changes to about:config. In the months my last comment on that bug that until today, Firefox only crashed a couple of times for me. Now, many of the webrender settings I'd changed in about:config to prevent the crashing are gone... so, logically that seems like an obvious explanation for why it's now crashing again?

Actual results:

Firefox crashes when trying to write a post on blogger.com. No clear reason to explain why it crashes when it crashes, it just suddenly crashes when typing a blog post.

Expected results:

Firefox shouldn't crash when writing a post on blogger.com... it has never happened before when writing a blog post, but started with the recent update.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Graphics
Product: Firefox → Core

Can you provide a link to the crash report from about:crashes?

Does the problem still happen in a fresh profile?

Flags: needinfo?(seko.idiootti)

Here's the most recent crash: https://crash-stats.mozilla.org/report/index/bcdda2d3-3e4e-4a4b-a4a4-d69200220122

With a default profile, I can't even try it because the browser window flickers with horrible glitches (like in the screenshot, my desktop "leaking" through the window; when I moved the mouse, the glitches moved to different places, and parts of the screen briefly went full black) just like the worst glitches described in the previous bug report I'd filed. With the default profile, while this is happening, Firefox uses 60-100% CPU with only the default new tab open, and my laptop starts to get really hot within like ten seconds... so I can't even try if this happens.

Flags: needinfo?(seko.idiootti)

I noticed these settings had changed with the latest update, so I changed them back to be like this:
gfx.webrender.software = true
gfx.webrender.software.d3d11 = false

And this seems to have fixed the crashing when writing a post on blogger.com. Firefox as a whole is a little bit slower with these settings, but that's of course preferable to crashing. I don't understand what the settings mean, but clearly they make all the difference; does it mean Firefox uses too much memory with the different kind of webrender settings, which my old potato laptop can't handle? Well, I hope they'll remain changeable in the future too...

So, with gfx.webrender.software.d3d11 set to "false", it causes the corruption of icons that also happened previously. With it set to "true", that doesn't seem to happen. Earlier that setting made no real difference. Not sure what's up with that, but... hopefully it won't start happening with that setting changed to "true" again now.

Anyway, this clearly means the crashing on blogger.com happens only if gfx.webrender.software is set to "false".

Do we need to apply blocklisting so this device gets software WR by default? about:support in https://bug1729779.bmoattachments.org/attachment.cgi?id=9240176

Flags: needinfo?(aosmond)

I don't think this is a driver issue if the crash reports are similar to the one in comment 3. That's an OOM. Discussions with jrmuizel indicate D3D11 compositing will use more memory. Maybe we need to look at the OOM crash rates for 32-bit users to make an assessment if any should just get SW-WR.

Flags: needinfo?(aosmond)
Blocks: wr-oom
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows 7
Hardware: Unspecified → x86

I should note that the crash report indicates ~2 GB of virtual memory and ~3 GB of physical memory (in case the report is discarded in the future). <= 3 GB is around 26% of our users apparently, according to https://firefoxgraphics.github.io/telemetry/#view=system

I think availability of virtual memory is the bigger problem here.

Severity: -- → S3

So, it happens again with the latest update (or some recent update; the last blog post I made was on the 3rd of March and there were no problems, and now I tried writing one today but it crashes). Now the crashing happens even with "gfx.webrender.software" set to "true", which I guess means there isn't any way to prevent it anymore, since that was the setting that fixed it previously and I don't think any other settings are different.

It's confusing to me because this was again the first time Firefox fully crashed in months (and had a crash report), and again it was when writing a post on Blogger. There have been a few tab crashes occasionally, but those have happened only on pages absolutely full of stuff when Firefox has used like 70-80% of physical memory (eg. on sites with infinite scrolling, after scrolling down really far). But full crashes like this, it hasn't happened even once since the previous times it crashed when writing posts on blogger.com...

Here's the crash report from just now: https://crash-stats.mozilla.org/report/index/2a2ff48a-37fa-4125-9d25-add980220428

Since 100.0.0, Firefox has started crashing a lot more. It's basically guaranteed to crash:
A) If I have maybe 10+ tabs with just images on them open at the same time; it'll usually crash when switching tabs
B) If I right click on an image to save/copy it, especially if I have 5+ images open in different tabs or even just one large image; sometimes just the tab crashes, but usually the entire browser
C) Quickly switch back and forth between pages that have a lot of images or videos or stuff on them (or different tabs with just an image on them)
D) If I'm trying to write a post on Blogger, as already began to happen earlier
Sometimes it'll crash completely at random, or at least I can't tell what causes it sometimes.

One thing I just noticed is that "gfx.webrender.enable-multithreading" has been removed as an option (in the past I'd had to change it to "false" to prevent crashes and such), but there is instead "gfx.webrender.multithreading" now that's set to "true". I'll try changing it to "false" and see what happens.

Changing "gfx.webrender.multithreading" to "false" seemed to help at first (I was able to start writing a post on Blogger for 30 minutes), and not only that but it seems Firefox as a whole is significantly faster with this setting (which is the opposite from how it was in the past), but then it crashed. So, it doesn't fix the problem, unfortunately.

I'll try switching "gfx.webrender.software" to "false" and see what happens...

Well, it worked for three hours... I managed to very nearly finish writing the post on Blogger without it crashing again, and already thought "this was the solution", but then it crashed. The entire browser seems to be slower with "gfx.webrender.software" set to "false", though, and both CPU usage and memory usage might be higher?

I'll have to try with "gfx.webrender.multithreading" set to "true" while "gfx.webrender.software" is set to "false". Probably not today, though... (and sorry for so many posts)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: