This morning I upgraded from 39.0.3-1.fc22 to firefox-40.0-3.fc22 and after running the suggested tests (addons, browse, media) and some casual browsing I left positive karma in bodhi. I was aware of other users reporting crashes in bodhi, but I hadn't seen any until after ~7 hours. There were a couple more crashes in relatively short time so I tried the workaround (layers.offmainthreadcomposition.enabled set to false) but it did not help, so I think you might need to put that 40.0-4 update on hold. This is a crash report with layers.offmainthreadcomposition.enabled = true: https://crash-stats.mozilla.com/report/index/4d678ff7-f036-4d68-bf86-6a5172150812 and this is with the option set to false: https://crash-stats.mozilla.com/report/index/f83e6fca-563b-455f-8b70-7f86a2150812 The corresponding messages from the kernel: [ 4218.123030] Chrome_ChildThr[32163]: segfault at 0 ip 0000000000407410 sp 00007fd7a0443430 error 6 in plugin-container[400000+39000] [ 4218.124269] Chrome_ChildThr[23825]: segfault at 0 ip 0000000000407410 sp 00007fb9a9d43430 error 6 in plugin-container[400000+39000] I can't find anything useful with journalctl or at least I'm doing it wrong... I have no idea which plugin might be responsible -if the culprit was indeed a plugin- but my current firefox setup has been stable for years. Firefox lists the default theme as the only extension that was recently updated and I had updated flash (which I don't usually run, it is set to always ask) yesterday when I was still on 39.0.3-1 and I didn't get any crashes. I did notice that the crashes happened when there was a quick redraw on the screen (switching/closing tabs, flipping through images) but not when playing html5 or flash videos. I can't find I way to reliably reproduce the crashes though. You can see my system specs in the crash reports above (e.g. GeForce 9800 GT graphics card with the 340.76 driver) but I also got the same crashes after the 40.0-3 update on an Aspire VN7-791G, using the intel driver which had also been running fine for some time. It also crashed with the layers.offmainthreadcomposition.enabled set to false but it did not have crash reports enabled at the time, so I don't have anything to show at the moment. I couldn't find a relevant report in mozilla's bugzilla, so if it is not a build-specific issue, it might have something to do with our patch set. I will run some tests with a clean profile tomorrow, if Jan has any ideas, I am open to suggestions and willing to be the guinea pig.
I have the same kernel messages about segfaults, e.g.: [20326.072917] Chrome_ChildThr[8062]: segfault at 0 ip 0000000000407410 sp 00007f95fe642470 error 6 in plugin-container[400000+39000] [48338.137221] Chrome_ChildThr[10757]: segfault at 0 ip 0000000000407410 sp 00007fd490242470 error 6 in plugin-container[400000+39000] However, I don't think this is actually caused by a plug-in, simply because I don't have any enabled. (The only thing I have that's not stock to the basic Fedora package in Add-Ons is a supplemental spell checking dictionary that hasn't been updated in a while. I seriously doubt that's the culprit in my case. I do see the original reporter also has two dictionaries installed, though, so we have that practice in common.) I'm not able to specify exact behaviour to duplicate this, as it varies considerably each time. Sometimes it'll crash while trying to recover the browsing session from the last crash. Like the original reporter notes, it does seem more prone to crash if I'm quickly moving between tabs or applications while there's animated content of some kind, but it has also crashed on me when I've been browsing only simple sites with basic text and static graphics. (And it has also successfully handled HTML5 content without crashing in proximity.) I have mozilla-crashreporter-firefox-debuginfo-40.0-3 installed, but from what I can see, it doesn't provide any additional information beyond what was captured in initial crashes.
There was a reddit user who had found a couple of ways to crash firefox: https://www.reddit.com/r/firefox/comments/3de66f/400_crashing_all_the_time/ Could someone test his scenarios with and without OMTC? I do not have reddit or 500px.com accounts.
Thanks for the reports, I've spend today debugging this problem I'm quite sure it is related to flash plugin. For example I've been able to reproduce the crash on having more tabs with stream.cz videos and quickly switching between them as mentioned in both comments. So if possible try to disable flash in Addons. > David H. Gutteridge Are you sure you don't have flash installed/enabled? In this case, try to set javascript.options.baselinejit to false. I've filled https://bugzilla.mozilla.org/show_bug.cgi?id=1194216 on upstream, and also commented https://bugzilla.mozilla.org/show_bug.cgi?id=1182507 That's what I've hit on my machine with debug build.
(In reply to Jan Horak from comment #3) > Thanks for the reports, I've spend today debugging this problem I'm quite > sure it is related to flash plugin. For example I've been able to reproduce > the crash on having more tabs with stream.cz videos and quickly switching > between them as mentioned in both comments. > > So if possible try to disable flash in Addons. I've been at it since morning as well, I'm moments away from an epileptic seizure from all the rapid tab switching/closing but I can't blame flash for this one. I have tested all possible combinations of fresh and old profiles, flash enabled, flash installed but disabled, no flash at all, OMTC on and OMTC off. I haven't had a single crash with OMTC disabled (yet), regardless of the state of the flash plugin or the "freshness" of the profile. My guess is that yesterday I failed to restart firefox after changing the option. Should it have been restarted?
I do not have Flash installed, quite deliberately. Since toggling the layers option off, I haven't encountered any crashes (yet). I won't have access to the machine in question to do further testing until next week, so the outstanding question about the other config option will have to wait until then.
Okay, I'll try to push 40.0-4 into testing which has OMTC disabled. It seems it bring some remedy to this crashes. However we need to investigate more. Now the priority is to deliver security update as soon as possible. Thanks for the feedback!
(In reply to Jan Horak from comment #6) > Okay, I'll try to push 40.0-4 into testing which has OMTC disabled. It seems > it bring some remedy to this crashes. However we need to investigate more. > Now the priority is to deliver security update as soon as possible. FYI, 40.0.2 was released yesterday: https://www.mozilla.org/en-US/firefox/40.0.2/releasenotes/
(In reply to Xose Vazquez Perez from comment #7) > FYI, 40.0.2 was released yesterday: > https://www.mozilla.org/en-US/firefox/40.0.2/releasenotes/ Thanks for heads up, I've already check that update and it seems to be only relevant to Windows (10) users. So we don't need it for now.
(In reply to Jan Horak from comment #6) > Okay, I'll try to push 40.0-4 into testing which has OMTC disabled. It seems > it bring some remedy to this crashes. However we need to investigate more. > Now the priority is to deliver security update as soon as possible. > > Thanks for the feedback! Some people who experienced crashes with firefox 40 when it was in beta or aurora (can't remember, didn't keep the links) reported that they went away in versions 41 and 42. Do you think that testing these builds with the current patch set would be helpful at all?
(In reply to Jan Horak from comment #8) > (In reply to Xose Vazquez Perez from comment #7) > > FYI, 40.0.2 was released yesterday: > > https://www.mozilla.org/en-US/firefox/40.0.2/releasenotes/ > > Thanks for heads up, I've already check that update and it seems to be only > relevant to Windows (10) users. So we don't need it for now. Firefox release manager here, I confirm that 40.0.2 is Windows only. Please note that this bug spiked on GNU/Linux since we released 40: http://bugzilla.mozilla.org/1145230 We might do a 40.0.3 for this top crash.
Reporter, can you please test firefox binary from mozilla.com? Also please create a new clean profile for it ($firefox -ProfileManager). To make sure it's a problem in Fedora Firefox build.
BTW. I'm unable to reproduce with mozilla binary, seems to be Fedora specific.
I downloaded the 64-bit version of firefox-40.0.2 and I have been messing with it for the past three hours, but I can't get it to crash. Its default option is to have OMTC enabled. At some point I had ~20 tabs with ad-filled pages and all of them playing videos, I held Ctrl-PageDown to keep circling through them, no crash. I did notice one thing, but I don't know if it is somehow related: I am using GNOME's dark theme, as it is easier on the eyes, but it's messing with input fields and other visual elements on some pages. In my normal profile I have unchecked the option to use system colors which fixed this for some of the elements on some of the problematic pages, but not for all of them. Mozilla's binary did have dark window titles, but not darkened awesome and search bar fields and also the pages that I have trouble with were rendered without any problems. Our versions of seamonkey and icecat seem unaffected by the use of the dark theme as well, save for their window titles. How does firefox differ in its integration into the theme? Could that have anything to do with the issue at hand?
Please, keep in mind that it took me over seven hours of using firefox to get a crash in the first place, so the results might not be definitive (yet). I'll keep using mozilla's binary with the fresh profile for a couple of days and see if anything noteworthy happens. As for our builds, after switching OMTC off, I haven't had any more crashes in the last three days.
Okay, Thanks.
Concerning the question in comment 3, setting javascript.options.baselinejit to false doesn't make any difference on its own in my case. If layers.offmainthreadcomposition.enabled is set to true, crashes still occur frequently.
Almost two and a half days of using mozilla's build with a fresh profile and I haven't had any crashes. Yesterday I added all the add-ons and plug-ins that I regularly use one by one and it remains rock solid.
Thanks for the report, closing as currentrelease.
Any ideas as to what's causing this?
It's caused by system cairo library.
So are we waiting for a fix from cairo or mozilla? Is it tracked someplace?
Mozilla already fixed the issue in Cairo... So, it won't come from Mozilla I think.
We're going to switch to mozilla in-tree cairo in next release.