Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

Firefox 6.0.2: Periodic freezes every minute (60")

  • 28 uphendule
  • 25 zinale nkinga
  • Igcine ukuphendulwa ngu Michail Pappas

more options

My problem is as follows: everything worked fine with my Firefox on all my computers. All of them were sync'ed with firefox sync (including my mobile).

Then, on my Windows 7 Home Premium 64-bit desktop (Q9450 CPU, 4Gb of RAM, Asus P5KC motherboard Intel P35-based), I replaced the motherboard and the CPU. Obviously I reinstalled Windows from scratch and Firefox as well. From plugins, I installed only Adblock plus with the Easylist and malwaredomains lists. The same plugin (along with others) were installed previously on my desktop. I initiated a new sync and my bookmarks and everything obviously appeared ok.

On this new hardware platform (Q9650 CPU, 8Gb RAM, Asus Rampage Extreme, Intel X48-based) I experienced strange freezes, which felt that they ranged from 10" to 30". These happen while I am trying to do an action, like fill in a form for example. Firefox does not freeze while it is idle. When this freeze takes place, it affects only firefox. Nothing else gets affected. Made a clean uninstall, re-installed with only adblock plus and enabled firefox sync. Same issue...

It drives my crazy because both the motherboard and the cpu are better than the one I used to have. The system is not overclocked. All my other firefox installations work perfectly.

I should add that I also tried checking with certain sqlite commands the integrity of all sqlite databases. All were ok. Additionally, I deleted this system from sync, completely uninstalled ff, deleted the relevant Application data subdirectories and made a fresh install, only with adblock plus and re-enabled sync. Same issue. Also tried using other memory DIMMs. Same thing again.

Atm, it feels like this is either motherboard related OR there is a "blocker" somewhere. What strikes me a lot is that it works perfectly on all my other computers (remember that all of them are firefox sync'ed) and that the problem appears on the strongest of these machines...

I've read some bug reports in bugzilla that *seem* to be similar to mine, but can't quite correlate the same. Then I stumbled an excellent process explorer from winternals (mentioned in this thread here as well), which you can get from

Running this process explorer along firefox I noticed that initially all seem fine. Selecting View -> System Information I watched what happened while browsing. Initially, browsing causes some small spikes. Then something *very* strange happens (see attached pic):

   Every 120" cpu load rises for approximately 60".
   During the 60" cpu peak, firefox exhibits the freezing
   firefox is ok during the rest (120-70=50") of the time only! 

Note that this behaviour does not appear immediately at firefox start, but rather appears later on. I can not pinpoint the exact cause at this point. Once this 2 minute cycle starts, it does not stop until firefox exits!

Perhaps this should be submitted as a bug directly, but it felt like I had to gather some expert opinion here to help me and the devs on this.

EDIT: Updated info. From sysinternals, I can see that when the 60" peaks take place, cpu time is dominated by thread MOZCRT19.DLL (see 2nd screenshot). During that time, the following seem to be causing the peak:

mozsqlite3.dll!sqlite3_reset+0x2db1 mozsqlite3.dll!sqlite3_step+0xd9 xul.dll!?CanUseOpaqueSurface@Layer@layers@mozilla@@QAEHXZ+0x1d81 xul.dll!?CanUseOpaqueSurface@Layer@layers@mozilla@@QAEHXZ+0x1c58 xul.dll!?CanUseOpaqueSurface@Layer@layers@mozilla@@QAEHXZ+0x1bc6 xul.dll!NS_GetXPTCallStub_P+0xb59 xul.dll!?IsOriginalCharSkipped@gfxSkipCharsIterator@@QBEHPAH@Z+0x28f9a xul.dll!?GetEffectiveClipRect@Layer@layers@mozilla@@QAEPBUnsIntRect@@XZ+0x659 MOZCRT19.dll!_endthreadex+0x78 MOZCRT19.dll!_endthreadex+0x106 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36

Okulungisiwe ngu Michail Pappas

Isisombululo esikhethiwe

Your bug was resolved as a duplicate, have you tried the workaround in

It would appear the 64bit comments were a red herring, bug 686025 now having been marked as all platforms.

Funda le mpendulo ngokuhambisana nalesi sihloko 👍 1

All Replies (20)

more options

Images from the original post are attached here.

more options

And some even more info: I have firefox installed on 3 desktop systems and on my mobile. All of them are Firefox sync'ed (bookmarks, passwords, history, tabs). All 3 of my 4 systems operate without a hitch. This problem appears on the 4th system, which happens to be the the most powerful and the one having the smallest number of extensions installed.

I have tried safe mode, disabled plugins, disabled graphics acceleration. No go.

I have opened bug report 688521 (see ) for this issue.

After opening the bug report, I bumped upon the excellent "process monitor" application by Sysinternals. Having it run alongside firefox, I noticed that the freeze start coincided with two lock/unlock operations, on file places.sqlite-shm:

   The first, was a LockFile operation (exclusive: false, offset: 123, length: 1, fail immediately:true) thas was succesful
   The second was an UnlockFileSingle operation (Offset: 123, Length: 1) that was also successful. 

Then, firefox does nothing for approximately 39". As far as cpu load is concerned, during these 39" cpu load rises to 100% with firefox being the dominating process. Specifically the mozsqlite thread. Things return to normal coinciding with an UnlockFileSingle operation for the same file and for the same offset:

   UnlockFileSingle (offset: 123, length: 1) success. 

Really hope someone can try process explorer/monitor and perhaps confirm my findings...

more options

From the other thread that was the relevant discussion, it so happens that all those having problems were on 64-bit windows. From my own 4 systems, the one having the issue is the only one on 64-bit. Some correlation there? However, before the memory/cpu/motherboard update, ff (5?) was running on the 64-bit system without a hitch.

Just saw that 7.0 was released, promising better memory management among others, see .Unfortunately for me I'm out of town, writing this on my firefox 7.0-powered netbook (which has never exhibited the same problem my desktop does).

more options

Good luck with tracking down this problem, here are a few suggestions that may be worth considering (you or others may have better ideas)  :)

Hopefully someone will have a go at your bug report, the first stage of triaging that is to try to confirm and reproduce it. I note the original thread /questions/872283 now has votes from 608 people with 194 new this week, a very high score for this forum, however many may have similar symptoms from different causes, and few users are able or willing to make the effort and have the time required to file bugs and carefully look at the problem.

If the problem is down to the motherboard, it may be rather unusual, and unlikely others will easily replicate the problem. To make this easier for anyone trying to help may I suggest simplifying things as much as possible.

If using multiple versions it is safe to manually delete the nightly profile folder, and it will be recreated, but do not use the uninstall option on any version that says remove user settings (however it is worded) it will attempt to remove all profile data, all settings and passwords from all versions of firefox that are installed. Such an action is not intuitive, and only reversible with luck and timely use of file undelete tools. As a precaution it may be worth copying profile folders and their contents somewhere safe away from the paths used by Firefox program files or profile files.

Install firefox from the Nightly channel, it probably by default uses its own profile and programme path, if not choose a custom install. That has the advantages

  • you are using the most recent version of firefox, something the developers are likely to suggest is tried when confirming a new bug in bugzilla
  • you can leave your other firefox version browser for day to day browsing and leave it synced with all its bookmarks & settings /customisations
  • you can even make your own comparisons between the two installations, even for interest running them both at the same time side by side. (use the no remote option)
  • you now have a clean install to test and are able to report that in your bug688521 you need to try to make precise statements of simple minimal steps to reproduce the problem

With a bit of luck many others from these threads with 64 bit systems will be able to reproduce the problem following the new steps to reproduce. (64 bit system use could be a red herring, because 64 bit systems are now getting a lot more common, but I did notice that as a possible factor )

I have probably mentioned this before, but have you all done all you can to rule out

  • that the problem is malware see for example Troubleshoot Firefox issues caused by malware
  • due to security software or firewalls etc (see Configure firewalls so that Firefox can access the Internet )
    • at least mention in the bug and this thread what software and firewalls are in use
    • it is obviously risky to run without such security software and firewalls but you could consider trying that briefly (see my next comment about offline use)
  • do you get problems with offline use of firefox, or given that you have several computers on an intranet (that should reduce the security risks if you disable security software and firewalls)

Sorry if the suggestions are repeating what I may have mentioned in the other thread, but they are now all in one place, and easily available to anyone reading this thread.

If anyone is able to recreate,the problem, I suggest, start a new thread, that then includes all your system info, and any specifics, and cross link the threads with a comment and a link.

Okulungisiwe ngu John99

more options

Let me thank you first for your extensive post. I have been working as a systems/network administrator for years. I'm not the best, but I do try hard to isolate issues around.

In this case, all my systems are crystal clean. If something does ever sweep into my system, I'll call it McGyver :)

Using nightly builds is a tad difficult for me: I really have minimal time available, and my system-at-fault is a production one. I'll try 7.0 when I get back, which will be in 1-2 weeks ...

Like I said, I can isolate two or three things about this:

  • Issue appears periodically -> hence there's some specific code that has a periodicity of 30" - 90"
  • Issue *seems* to affect 64-bit systems only?
  • Issue possibly has something to do with sqlite as implemented in 6.0.2 and with access on places.sqlite*

Main purpose of this thread here is to isolate, if possible at all, exact cases like mine and perform identification of common factors (if possible).

more options

Locked or Damaged places.sqlite

Check and tell if its working.

more options

Thanks for the pointer, I checked out those things before making my first post in these forums. No resolution unfortunately,

(In my bug report I have added that twice I made a clean start, after complete uninstall. Issue persists.)

Okulungisiwe ngu Michail Pappas

more options


I was not suggesting that you do the nightly builds/compile, or that you necessarily even bother to update it on a nightly basis, merely install that version in its own path with its own clean profile.

Does this problem appear immediately, if so it is only going to take the few minutes to install firefox 9 or 10 and the few minutes until the problem occurs.

If the problem does not appear immediately then what further steps are necessary to recreate it, and can you confirm a couple of sites on which the problem does occur. Also as I asked earlier, does the problem occur if working offline ?
(if so maybe it would help you create a test case, else it may be pointer towards the cause)

If you suspect the problem is with places.sqlite use then use a new profile containing a minimal places.sqlite, possibly the default one created on new install, with only your named tabs as additional bookmarks. If you install an additional version of firefox, you can leave the production one alone for day to day and production use.

If you discover the problem is specific to Firefox 6.0 then the update to Firefox 7 will solve your problems.

more options

@john99: apologies for the late reply. I did understand your context. Days before I did try using a completely empty profile and I did not manage to reproduce the issue, even with 6.0.2. However, once my firefox syncs the issue appears.

Like I said, in all my other platforms (Windows XP Pro 32-bit, Windows 7 Starter 32-bit, Android 2.3.3), this problem does not appear at all. It is only on my Windows 7 Home Premium 64-bit that this problem appears.

Checking around bugs solved in 7.0, one can see that there have been changes to sqlite in ff. Changes that just might have caused this bug to appear in 6.0.2.

So, the question remains: does this appear only in 64-bit or is it also a 32-bit issue?

more options

As a standard course of action anyone triaging the bug is likely to use safe mode and a clean profile, and probably a nightly version of firefox when trying to reproduce and confirm the bug as New. As it currently stands your bug is in danger of being resolved WorksForMe or left forever Unconfirmed because of a possibility it is hardware specific. Remember also Firefox 6 is now no longer supported, if the problem is version specific it is not going to be investigated.

You have not mentioned in the bug that you have no problems in safe mode, and that it is only after you sync that the problem occurs, that is surely vital information. You should consider adding that information to the bug, and maybe editing this thread's opening post to make that clear. (Consider editing the bug title and keywords ?)

Most users do not give the amount of detail you do, and whilst I have mainly noticed users with 64 bit systems reporting freezing problems, there are also 32 bit reports. I am unsure whether the 64bit correlation is real, or an artifact due to

  • the sample is self selecting, users seeing 64 bit post in that thread
  • the fact that I assume 64 bit systems are becoming much more common on the userbase.
  • ( one advantage of users starting a new thread for their own problem is we then usually see the system details, and UAS)

No need to politely apologise for slowness in replying, it is your problem and thread, work at the pace that suits yourself and in accordance with how important the problem is to yourself.

I have also mentioned previously in this and the other thread the problems could be security / firewall related. Saying

In this case, all my systems are crystal clean. If something does ever sweep into my system, I'll call it McGyver :) 

may be an indication that aggressive and duplicated security systems are involved with the problem, more detail about them may help.

edit someone with bugzilla edit privileges is already looking at your bug

Okulungisiwe ngu John99

more options

By "In this case, all my systems are crystal clean. If something does ever sweep into my system, I'll call it McGyver :) " I meant that my systems are minimalists one: no personal firewall running at all, apart from the windows one. No double and triple layers of protection, like AV, extra anti-trojan etc. For example my systems have either MSE, or Avast Free, or NOD32 (the AV product and not the complete security suite). On my task bar, only 6-7 icons are shown. Like I said, minimalist systems, without screwing around, shutting down services for things I really do not have a clue what they are about. Add safe hex practices, well you get the idea...

I agree about this thing with the bug: I'll have to check whether I have the same issue with ff 7 and update the bug report. Really hope that it won't end up as worksforme, by now I hope the developers have understood that in my case the issue is rather (a) pinpointed and (b) the poster (that is me) can provide extra debugging info on demand.

Okulungisiwe ngu Michail Pappas

more options

You can use undo to revert the thread as being unsolved.

more options

@mha2007: Thank you :)

more options

So the problem computer has Firefox 6 at present, Windows firewall, and what other security related software? that may be relevant to the problem. Your other computers may have one of the other combinations you listed, and they work without freezing.

Lets also of course remember you say

  • you do not have the problem in safe mode,
  • and if I understand you correctly it is after you sync,
    and although that of course will suddenly change/increase your places.sqlite content, it does not cause problems on your other machines

Does the freezing problem continue long after the sync process has completed on other restarts of the computer, and does the sync process appear to complete correctly ?

more options

ESET NOD32 antivirus is also installed, but I did try completely disabling it and the problem persisted.

Your summary is correct: no (reproducible) issue in safe mode and issue appears when places.sqlite etc are not empty.

The sync process appears to complete correctly each time. Freezing occurs even after restart. Once started, it continues until firefox is closed. If firefox is closed during the freeze, its window closes but the process remains frozen. After this 30"-60" period passes the process disappears.

(OT: How can I quote other posts here?)

more options

How can I quote other posts here?

Copy the text you want to quote and change its style to Italics.

more options

You may also link to individual posts /questions/880177#answer-253765 but not easily, unlike the contributors forum, public links are not normally provided and there is not a Reply option or support of <blockquote>

I think that is intentional. These support forums are intended to be single topic threads, on the subject as asked by the Original Poster. (Although that is not fully explained in the markup kb or elsewhere afaik))

more options

Isisombululo Esikhethiwe

Your bug was resolved as a duplicate, have you tried the workaround in

It would appear the 64bit comments were a red herring, bug 686025 now having been marked as all platforms.

more options

I agree with your comment about 64 bits. Thanks also for your feedback in my bug submission, much appreciated. Just read the entire description of bug #686025, really glad the firefox lads confirmed the problem's existence and narrowed down possible cuplrits. I'm even happier that my hardware is not at fault here, weeeee \o/

Will be back in town on Wednesday, I'll track things down from the bug report from now one.

Thanks a zillion for the all the help so far :)

@john99: I'll be more than glad to mark your last post as a solution, if my testing on Wed makes the issue disappear :)

more options

I Hope it works,

but there are other possible potential causes of these hangs. You did say there was no problem in safe mode, the bug referenced did occur in safe mode so you could yet find that is not the cause of your problems. I was one of the people noting a possible correlation with 64 bit systems but hedged the bet by pointing out 64 bit systems are now more common so it may not have been causative.

This issue points out the need to balance looking at both individual threads where a problem is reported, and the high scoring threads

  • high votes indicate a problem seems to be widespread, but not defined
  • individual threads allow the problem to be looked at and potentially a bug filed

An advantage of posting a support question or looking at those initially instead of filing a bug straight away is that it gets a rather larger exposure, the disadvantage is the lack of detail in many support questions.

Unfortunately the forum questions are answered mainly by volunteers, and there are more questions than can be effectively answered. (Forum changes are being planned, maybe it will improve)

  1. 1
  2. 2