MASTER firefox theme crash

Bug #45008 reported by Kreuger Burns
204
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Critical
firefox (Ubuntu)
Fix Released
High
Mozilla Bugs

Bug Description

PLEASE DON'T POST ANY MORE CRASHES HERE.

This is the MASTER bug for CRASHES and FREEZES on CHANGING THEME change in gnome:

NOTE: most stacktraces in this report might not be due to theme switches. those are tracked in bug 72018

STEPS TO REPRODUCE this issue:

1) Start our app (Firefox, Seamonkey, Thunderbird, whatever; make sure it's a
   GTK2 build)
2) Open some windows (a dozen should be good)
3) Open gnome-control-center
4) Select the "themes" item
5) Switch the current theme

Tags: mt-eval
Revision history for this message
Kreuger Burns (car-crazy33) wrote :

It also crashes when trying to modify some settings and adding bookmarks.

Revision history for this message
Phil Bull (philbull) wrote :

Thanks for the report. What happens if you disable all of your extensions?

Revision history for this message
Kreuger Burns (car-crazy33) wrote :

It made no difference. I just tried removing my theme (Silverskin) and was able to customize it (right click near the top -> customize) it kept crashing before so I think now the skin may be at fault.

Revision history for this message
Phil Bull (philbull) wrote :

OK, what happens if you use a different theme?

Gaëtan Petit (gaetanp)
Changed in firefox:
status: Unconfirmed → Needs Info
Revision history for this message
Kreuger Burns (car-crazy33) wrote :

I just stopped using themes. Now it seems to just lock up and I have to kill it though. Happens quite a bit so one of the plugins might still be causing problems.

Revision history for this message
Phil Bull (philbull) wrote :

Hmmm, could you uninstall and then re-install the firefox package please? It might be worth deleting the .mozilla directory in your homedir in case it's a setting causing this problem. I'd suggest backing it up before you delete it, though.

Revision history for this message
Kreuger Burns (car-crazy33) wrote :

I'll get my bookmarks and reinstall it then.

Revision history for this message
Kreuger Burns (car-crazy33) wrote :

Now I can't get java installed for firefox again. That was the first time I've ever gotten it working. (It wasn't the problem, I installed it after) Firefox seems to be fine now though. And I didn't reinstall downloadstatusbar

Revision history for this message
Kreuger Burns (car-crazy33) wrote :

Okay I got Java working again. Just had the wrong directory.

Revision history for this message
Phil Bull (philbull) wrote :

OK, so you're up and running again? If you're not seeing the problem any more, I'll close the bug.

Revision history for this message
Kreuger Burns (car-crazy33) wrote :

Yes it seems to be working fine. I guess it was the skin after all. Although the flash plugin doesn't display properly but I don't think that matters for this bug.

Revision history for this message
Oliver Klee (launchpad-oliverklee) wrote :

This possible is related to #28662 or #53355.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

STEPS TO REPRODUCE:

1) Start our app (Firefox, Seamonkey, Thunderbird, whatever; make sure it's a
   GTK2 build)
2) Open some windows (a dozen should be good)
3) Open gnome-control-center
4) Select the "themes" item
5) Switch the current theme

EXPECTED RESULTS: Theme changes, all is well

ACTUAL RESULTS: Theme changes, app starts taking 100% CPU. Been that way for 10+ minutes now. Sysprof says 25% of time in libXft, the rest of the time in libgkgfx. Sadly, this is a release (stripped and all) build, so that's all sysprof can tell me....

I'm told that if I wait long enough the app might start responding again. Maybe.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

I should note that if, God forbid, you don't have a current GNOME theme selected, simply opening the theme dialog will hang our app. That's what happened to me.

Revision history for this message
In , Steve-england (steve-england) wrote :

Dupe of / related to bug 318829?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Similar for sure. Might be a dup; hard to say. I'll try getting this profiled and fixed; at that point we can see whether bug 318829 is still around for that reporter. I wouldn't be surprised if there are multiple hang scenarios here...

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

So I waited for about 3 hours, with the app completely hung. Then I went to bed; in the morning things were ok... until I made the mistake of killing the gnome-theme-manager process, at which point the app went back to being hung. I'll probably try to get non-computer stuff done for the rest of the day, I guess, and see whether I can safely profile this somehow in the evening....

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

So the issue here is that with a single window and single tab open on a theme change we get 8 each of "notify::gtk-theme-name" and "notify::gtk-key-theme-name" all dispatched to 8 different widgets. This leads to 32 calls into nsPresContext::ThemeChanged, since nsWindow::ThemeChanged calls ThemeChanged on all child windows too. In practice, this means X calls to ClearStyleDataAndReflow on the chrome prescontext, X calls to ResizeReflow on the content prescontext, and 32-X calls to ClearStyleDataAndReflow on the content prescontext. I didn't bother to find out what X is. The upshot is that in my case I had 100+ documents open at the time of the theme change; reflowing each of them 30+ times just ... took a while.

Patch coming up that should make this saner. Certainly does over here.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Created attachment 237895
Handle GNOME theme changes lazily.

This is much faster. If we care, we could even suppress reflow in background tabs, but that would take a little more work... and I'm not sure that's desirable.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

Comment on attachment 237895
Handle GNOME theme changes lazily.

mPending* could just be PRPackedBools.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

> mPending* could just be PRPackedBools.

Er... good catch. I'll do that. Or rather make them bits in the bitfield we already have.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Created attachment 237902
Updated to comments

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Fixed on trunk.

Revision history for this message
In , Adam Guthrie (ispiked) wrote :

Verified FIXED using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060912 Minefield/3.0a1.

I had about 20-30 tabs opened in one window, switched the theme and Firefox recovered in < 1 minute.

Revision history for this message
In , Hussam Al-Tayeb (hussam) wrote :

Is it possible to get this checked in for 1.8 branch for firefox2?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

If someone ports it, does a bunch of testing, and then convinces the branch drivers to take it into an effectively code-frozen branch, sure. I really don't feel it's worth the trouble, myself.

Revision history for this message
In , Caillon (caillon) wrote :

Considering the major linux enterprise vendors will be shipping this, and this is not an uncommon task in the desktop, I think it should be worth at the very least consideration based on the fact that this hangs the entire browser.

Further investigation in the patch leads me to believe that this is scary only in the sense that "it touches the pres context", but a quick look at the patch tells me that at the worst, all this will break potentially is that theme updates don't get propogated at all (application still uses the old theme widgetry). That potential regression seems a smidgen better than hanging the entire application. But I can provide testing there, facilitated by the really easy backport. Creating a test build now with a backported patch I'll push after this is done.

Then of course, there are the platforms that don't hang, e.g. Windows (or does it? Not sure.) In which case better testing really *is* needed for those platforms which I am unable to provide, but hopefully others can.

With the small-ish risk involved and the considerably larger gain, I'd like to try and get this considered more seriously for branches. Are there known regressions from the trunk?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Chris, if you have the resources to deal with this, I have no problems with getting it in on branch per se. Just no time to do it myself. Please request blocking of 1.8.1 or 1.8.1.1 or whatever if you'd like this to block those.

Not sure what the Windows situation is, but it looks like it avoids most of the issues (at least if it only gets notified by the OS once), since it doesn't do the recursion thing GTK does. So I doubt there were hangs on Windows.

Revision history for this message
In , Caillon (caillon) wrote :

Created attachment 240193
Patch backported to Firefox 1.5.0.x

Only major differences here are the threading stuff, which needed to use the nsIEventQueue stuff.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Comment on attachment 240193
Patch backported to Firefox 1.5.0.x

Looks reasonable.

Revision history for this message
In , Adam Guthrie (ispiked) wrote :

*** Bug 356545 has been marked as a duplicate of this bug. ***

Revision history for this message
CarlosBoneti (carlos-boneti) wrote : Re: Firefox Crashes on Saving Files

I just had the same problem here. Firefox crashed when opening the save file window. It usually still works... I have, however the crash data.. that may help (or not)... By the way, I can't reproduce the error any more... :)

Revision history for this message
Kamil Toman (kamil-toman) wrote :

it looks that ff does not like large files to be downloaded...

Revision history for this message
David Farning (dfarning) wrote :

Hey Guys,

Thanks for your bug report.

How large are the large files you are referring to?

Could you please install firefox-dbg and try to obtain a backtrace (or crash report) by following the instructions on https://wiki.ubuntu.com/DebuggingFirefox This will greatly aid us in tracking down your problem.

Thanks
David

Changed in firefox:
assignee: nobody → dfarning
Revision history for this message
Hilario J. Montoliu (hjmf) (hmontoliu) wrote :

There seems to be a moderate number of reports with the same behaviour so unless someone thinks the opposite I'm going to merge those common reports.

The bug reports with same sythoms are: bug #45008, bug #64734, bug #65183, bug #68168, bug #70018, bug #70185, bug #70797, bug #71033, bug #72392, bug #72488, bug #72650, bug #73403, bug #74720, bug #75129, bug #75835, bug #75846,

We still need more information on this bug, so please any new comment/attach should go into bug #45008 as it might be the master bug of this problem. Please try to follow the hints in https://wiki.ubuntu.com/DebuggingFirefox it will be of great help for us in tracking down this problem.

description: updated
Changed in firefox:
status: Needs Info → Confirmed
status: Confirmed → Needs Info
Revision history for this message
John Vivirito (gnomefreak) wrote :

were all the backtraces the same in all the bugs? if not its a bad idea to make all as dups because there are more than 1 issues that can cause the same issue.

Revision history for this message
Hilario J. Montoliu (hjmf) (hmontoliu) wrote :

I've compared some of them and they look very similar (though I'm not a developer). I'm using apport-unpack and comparing the different Stactrace files. I'll review all the dups.

Revision history for this message
e_van (e-van) wrote :

Ff crashed during opening a .wmv file. It seems to be the same bug.

David Farning (dfarning)
Changed in firefox:
assignee: dfarning → nobody
Revision history for this message
Giorgos Koklas (geo-kok-deactivatedaccount) wrote :

In my case firefox crashes randomly when right-clicking on a link and choosing "save link as". The pop up dialog shows but everything freezes and ff crashes. Report is attached.

Changed in firefox:
assignee: nobody → mozillateam
Revision history for this message
edgyonr100 (apermyakov) wrote :

Same here. I'm installing dbg now, but for what it's worth, here is the debug info I got so far.

Revision history for this message
edgyonr100 (apermyakov) wrote :

This is reproducible all right. Attempting to download the podcast from http://video.zdnet.com/CIOSessions/?p=27 with "Save As" causes a crash. If it's of any significance, I played the podcast inside the browser first, then hit "Back" and "Save As" on the "download podcast" link. See attached gdb session log attached.

Revision history for this message
Freddy Martinez (freddymartinez9) wrote :

Seems to be confirmed.

Changed in firefox:
status: Needs Info → Confirmed
Revision history for this message
Leitet (lime) wrote :

Confirming bug. It often occurs, but not only, when starting several downloads in a row. If I'm f.x. downloading a lot of pictures from one site, (right-click save-as), then It's almost certain to crash after a few clicks.

Revision history for this message
TheAnonymous (da-nerd-mastah) wrote :

Bug confirmed in Ubuntu Edgy. Just occured once.

Revision history for this message
J C Nash (nashjc) wrote :

I can confirm failure in

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)

It's are REAL pain for me -- I'm supporting ~ 1000 students with two systems I wrote for homework delivery and return. When I want to check a particular assignment, I usually just have to click on it, but in last couple of days FF has been locking up.

Galeon actually dies trying to retrieve, so I suspect something "inside" the code-- haven't got debug installed yet, and with exams pending, won't get to it for a couple of weeks at least.

Konqueror is currently saving my skin.

Prof. J C Nash, U of Ottawa.

Revision history for this message
J C Nash (nashjc) wrote :

Hmm. On a different machine with apparently the same Ubuntu Edgy and same version (as in previous comment), things work OK. SInce I'm getting pdf files, I'm thinking some issue related to the plugins, in this case Adobe. Will try reinstalling some stuff.

Prof J C Nash

Revision history for this message
Alexander Sack (asac) wrote :

if you see this issue:

can you please test if starting in safe mode helps, aka:

 # firefox -safe-mode

if it does this problem is probably due to some extension installed. Please track down which one causes the problem by uninstalling one at a time until the problem disappear.

Maybe downloadstatusbar extension is our problem here?

Revision history for this message
Alexander Sack (asac) wrote :

setting to needs-info as we need a retrace run and info on the extension(s) that cause these troubles.

Changed in firefox:
status: Confirmed → Needs Info
Revision history for this message
J C Nash (nashjc) wrote :

1) Tried removing firefox and reinstalling (including removal of .mozilla directory).

No joy.

2) Tried
firefox -safe-mode

No joy, but terminal window had hundreds of
expr: syntax error
lines.

So seems not to be the extensions, at least not directly.

In case it helps, I have set up an example that causes the problem on my system (which doesn't seem to affect 1.5.09, or even 2.0.0.1 on some other systems -- very odd).

System for homework delivery is at
http://macnash.admin.uottawa.ca/etphp/
(trailing / important)
Log in as user 1234 with pw=tester. You will be seen as a teaching assistant by the system. Click the "Sample Assignment"
A Student, whose SN is 4321 (that login will work too with 1234/Student) has submitted "Accurate Summation.pdf" which causes lockup when clicked. Should offer Save / Open dialogue.

Am willing to continue to participate in helping to resolve this. As mentioned, Epiphany-browser and Galeon have troubles too, but Konqueror OK.

Revision history for this message
J C Nash (nashjc) wrote :

Attached is output (truncated by Ctrl C) of terminal when running in safe-mode.

The output from Galeon goes down to end of plugin msgs (no syntax errors -- just crashes). Epiphany gives same output in terminal when starting app from command line.

Because it affects all three browsers, seems like it might be something to do with link between the browser components and the Gnome support, such as a symlink or pointer not quite right, or permissions set in a way the app is not expecting.

jn

Revision history for this message
J C Nash (nashjc) wrote :

Well, I've SOLVED my problems with firefox.

Turns out acroread and the plugin connections had evaporated. Don't know why. Maybe one of the updates. Certainly I've done nothing to fiddle. However, there was a firefox update recently, and ....

I could get bad behaviour trying to look at a local pdf file, including the error msgs. Then found no acroread. Installing acroread, acroread-plugins and mozilla-acroread fixed things.

Will have to do the plugins for other browsers too.

Perhaps others can check if this is their problem.

JN

Revision history for this message
John Vivirito (gnomefreak) wrote :

Taking for retrace.

Changed in firefox:
assignee: mozillateam → gnomefreak
Revision history for this message
John Vivirito (gnomefreak) wrote :

kamil's Stacktrace. let me know if you can work with this.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Kamil's ThreadStacktrace

Revision history for this message
kjbull (eeck) wrote :

this is my crash log. the right click/save as crash sounds the same as mine. I noticed it after the Totem plugin couldn't play a file, I hit back, tried save as, and it crashed.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Carlos' Stacktrace.

Revision history for this message
In , Alexander Sack (asac) wrote :

any chance to see this on the branches at some point?

Revision history for this message
John Vivirito (gnomefreak) wrote : Re: Firefox Crashes on Saving Files

Marked as upstream.

Changed in firefox:
assignee: gnomefreak → mozillateam
status: Needs Info → Confirmed
Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Huh. Chris never requested approval?

Poke him to do it? Or do it yourself (with an explanation to drivers of why this should go on branches)? I'm happy to land the patch if it gets approved.

Changed in firefox:
status: Unknown → Fix Released
Revision history for this message
In , Alexander Sack (asac) wrote :

(In reply to comment #20)
> Huh. Chris never requested approval?
>

Chris, any comment? Any reasons that you did not request approval?

Revision history for this message
Solid1986Snake (patrick-schwalm) wrote : Re: Firefox Crashes on Saving Files [@nsFilePicker::Show]

This "featur" ^^ happens very often too me, independet form website ore file

Revision history for this message
John Vivirito (gnomefreak) wrote :

retrace

Changed in firefox:
assignee: mozillateam → gnomefreak
Revision history for this message
John Vivirito (gnomefreak) wrote :

Solid we need the FULL report including the coredump (the part you left out)

Revision history for this message
Solid1986Snake (patrick-schwalm) wrote :

Ok, after next crash I'll attach the full crash report, didn't save the old one.

Revision history for this message
John Vivirito (gnomefreak) wrote :

reassigning to team until we get crash report.

Changed in firefox:
assignee: gnomefreak → mozillateam
Revision history for this message
gazbert (gareth-lynch) wrote :

Hi

Firefox crashed when I saved a text file on ubuntu 6.10 using gedit.
Have attached the crash file.
Not been able to reproduce it.
HTH
/gazbert

Revision history for this message
Matheo (dj-matheo) wrote :

Firefox crashed trying to bookmark from the drop-down menu "Bookmarks>Bookmark this page" with mouse.

Was trying to bookmark this page:

 http://www.getlofi.com/wp-content/uploads/2006/10/atarilayout.gif

Cannot repeat behavior. Complete report attached.

Firefox 2.0.0.1
Ubuntu 6.11

Revision history for this message
John Vivirito (gnomefreak) wrote :

Taking for retrace.

Changed in firefox:
assignee: mozillateam → gnomefreak
Revision history for this message
John Vivirito (gnomefreak) wrote :
Revision history for this message
John Vivirito (gnomefreak) wrote :
Revision history for this message
John Vivirito (gnomefreak) wrote :
Revision history for this message
John Vivirito (gnomefreak) wrote :
Revision history for this message
John Vivirito (gnomefreak) wrote :

Finished retrace.

Changed in firefox:
assignee: gnomefreak → mozillateam
description: updated
David Farning (dfarning)
Changed in firefox:
assignee: mozillateam → mozilla-bugs
Alexander Sack (asac)
description: updated
Alexander Sack (asac)
Changed in firefox:
importance: Medium → High
Alexander Sack (asac)
description: updated
description: updated
Revision history for this message
In , Chris Thomas (CTho) (cst-yecc) wrote :

> Poke him to do it? Or do it yourself (with an explanation to drivers of why
> this should go on branches)? I'm happy to land the patch if it gets approved.

Do you mean just setting the flag and writing a comment?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Yes.

Revision history for this message
oerd (oerd) wrote :

In Gutsy, when changing the current gnome theme while firefox is running makes firefox freeze for some seconds.

Revision history for this message
gnudoc (gnudoc) wrote :

Following the steps above causes the theme to be changed after a delay of a few seconds (3s on my setup). The relevant upstream discussion is at https://bugzilla.mozilla.org/show_bug.cgi?id=352096.

Changed in firefox:
status: Confirmed → Fix Released
Changed in firefox:
importance: Unknown → Critical
To post a comment you must log in.