Closed Bug 883995 Opened 11 years ago Closed 11 years ago

Metro Firefox freezes after using it for a short while

Categories

(Firefox for Metro Graveyard :: General, defect)

x86_64
Windows 8.1
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: josh.tumath+bugzilla, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130617 Firefox/24.0 (Nightly/Aurora) Build ID: 20130617031112 Steps to reproduce: While using Metro Firefox, after maybe half a minute, the app completely freezes. I don't know exactly how to reproduce this, but after using the app for a while, it happens eventually. Actual results: All of the graphics are static, the app bar doesn't open and the list of settings in the settings charm don't load.
Severity: normal → critical
OS: All → Windows 8 Metro
Hardware: All → x86_64
Whiteboard: [triaged-on hold]
Josh, or anyone who can reproduce this hang, please follow these instructions for creating a process dump: https://developer.mozilla.org/en-US/docs/How_to_get_a_process_dump_with_Windows_Task_Manage If you are able to create a dump file, please make a comment in this bug and we'll figure out a way to get the dump file from you
OK. I have created the dump file. It's 442 MB.
Yeah unfortunately the process dump tends to be pretty huge; it should be the size of the memory footprint of firefox.exe when the dump was written, since it should contain all the memory that Firefox was using. On that note, the memory dump is a complete snapshot of the state of Firefox when you created the file, so it contains URLs of active tabs, history information, and possibly even passwords depending on what you were doing when the snapshot was taken. Sorry I didn't mention this previously! From the perspective of your data, it would be safer if you create a temporary Metro Firefox profile, reproduce the hang while using the temporary profile, and get a memory dump at that point. If you could, please follow these steps: 0) Ensure that metro Firefox is not running 1) Open a "Run" dialog (Window Key + R) 2) Type %APPDATA% and hit enter 3) Open the "Mozilla" directory 4) Rename the "MetroFirefox" directory to something else ("MetroFirefoxBackup" for example) 5) Launch metro Firefox - at this point, a new profile has been created and is in use (verify by checking that a "MetroFirefox" directory has been created) 6) Reproduce the hang without entering any info (URLs, usernames, etc) that you don't want included in the memory dump 7) Obtain a memory dump using the same steps as before After doing that, you can go back to your old Metro Firefox profile by doing the following: 0) Ensure that metro Firefox is not running 1) Delete the existing "MetroFirefox" directory 2) Rename the "MetroFirefoxBackup" directory back to "MetroFirefox" 3) Launch metro Firefox - you should now be using your original profile Sorry for all the additional steps! I just want to ensure that the memory dump you create doesn't contain any info that you want to keep safe
Hmm, that's interesting. I can't reproduce this in a new profile. I've been using that profile since before Metro Firefox landed in mozilla-central, so it seems the old data in it was causing a conflict somewhere. Touch wood, it doesn't seem as though I can reproduce this bug in a new profile. But thanks for the very detailed instructions you gave, Tim. Sorry for wasting your time on this. I'll mark this as WORKSFORME, but reopen it if I come across this freeze again in future.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
(In reply to Josh Tumath from comment #4) > Hmm, that's interesting. I can't reproduce this in a new profile. I've been > using that profile since before Metro Firefox landed in mozilla-central, so > it seems the old data in it was causing a conflict somewhere. Seems likely; we've had issues with old profiles in the past. > Touch wood, it doesn't seem as though I can reproduce this bug in a new > profile. But thanks for the very detailed instructions you gave, Tim. Sorry > for wasting your time on this. Not a waste at all! I truly appreciate that you've taken the time to file this bug in the first place and follow up with the debugging steps. I'm glad we were able to get your metro Firefox up and running. > I'll mark this as WORKSFORME, but reopen it if I come across this freeze > again in future. Sounds like the right thing to do. Cheers!
I'm also seeing this constantly with a profile that is not that old, though it is large (because it is synced to my very long-lived desktop profile). I'll see if I still get it after clearing my profile and re-syncing...
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Blocks: metrov1defect&change
No longer blocks: metrov1triage
mbrubeck do you know if you were using a build from 07-12 when you seen this? If not, do you still still this issue? (Wondering if somehow related to bug 890362)
I can reproduce this bug again. However, this time it takes longer to reproduce. I left the app snapped to the left and sitting for a bit. I had the task manager open in the mean time. The app was simply using 0.3% to 0.7% CPU. But suddenly, it jumped up to 30% without me interacting with it. Once that happened, the freezing started. But this isn't simply the case of a halt in the program somewhere; there must be a loop that's taking up CPU cycles in the main thread.
Blocks: metrov1planning
No longer blocks: metrov1defect&change
Blocks: metrov2planning
No longer blocks: metrov1planning
No longer blocks: metrov2planning
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WORKSFORME
No longer blocks: metrobacklog
Whiteboard: [triaged-on hold]
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: