Closed Bug 666128 Opened 14 years ago Closed 14 years ago

Frequent Firefox freeze and "Not responding" because the places database becomes corrupted

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 686025

People

(Reporter: sks3286, Unassigned)

Details

Attachments

(2 files)

koppah stack trace
12.53 KB, text/plain
Details
stack trace from fresh installation of FF9a1 on Win7.
45.76 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110620 Firefox/7.0a1 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110620 Firefox/7.0a1 Over past week or 10 days, I am observing that FF freezes frequently on Windows 7 for no apparent reason. The CPU utilisation goes up to 100% with FF taking the major share and memory usage exceeds 400mb. I say specifically Windows 7 because I am using the same build in Windows XP and Ubuntu in a multi boot environment without any issues. I have also tried disabling all plugins and addons without any result. Reproducible: Always
Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
Safe mode was still giving the same error. Created a new profile and been testing that. Last 30 minutes no issues. What do you think the problem is?
Version: unspecified → 5 Branch
I am also seeing this behaviour very frequently. I've upgraded to Firefox 6 Beta to see if it helps.
the issue is less frequent but occurs even with the new profile. The original profile is still practically unusable. @Koppah: do let us know if the beta works as expected
Version: 5 Branch → 8 Branch
Nope, it appears to still be doing it. :-( It seems like they don't last as long, but still an issue. Trying Safe Mode now...
Still the same issue with Safe Mode. Trying a new profile...
I also tried to set the affinity to only a single processor as I saw a very old bug (which was still open) where HyperThreading was causing issues - no luck. Any other ideas? This is very frustrating. I'm even considering switching to Chrome as it's getting too annoying!!
Please post the graphics section from about:support Your best bet to tracking this down will likely be to capture a stacktrace of the hang - see https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
I seem to be able to trigger this every time by trying to access the history menu. I'm working on a stack trace now, but in the meantime, here's my graphics info: Graphics Adapter Description NVIDIA Quadro NVS 295 Vendor ID 10de Device ID 06fd Adapter RAM 256 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.7536 Driver Date 5-26-2011 Direct2D Enabled true DirectWrite Enabled true (6.1.7601.17563, font cache 1.13 MB) WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611) GPU Accelerated Windows 1/1 Direct3D 10
Attached file koppah stack trace —
I attached the Visual Studio debugger as I was seeing another hang and it was stuck on a function called something similar to: mozSQLite3 This appears to happen when I click various parts of the UI, and in Safe Mode. For instance, I can guarantee for it to happen if I try to load the history menu (and it never seems to recover), but sometimes just by going to an address or clicking a bookmark item, it also hangs.
Ok, it seems like it might be a places.sqlite bug. I've deleted the file and am able to now access the history menu without getting a hang. I'm also no longer able to sync my Firefox Sync data, but that's another problem I'm looking into. :P
AFAIK ff uses sqllite to store history... so could explain why the browser hangs on accessing history if the process is locking up on sqllite... however i get the issue even while browsing generally ... and it is pretty severe in my default profile... every couple of minutes it locks up for 1-2 minutes...
(In reply to comment #12) > Ok, it seems like it might be a places.sqlite bug. I've deleted the file and > am able to now access the history menu without getting a hang. I'm also no > longer able to sync my Firefox Sync data, but that's another problem I'm > looking into. :P yes i had also taken up this line of investigation trying to disable the sync and then testing the browser... it improved slightly but still didn't resolve completely... i also observed that often pages with a lot of javascripts like maybe gmail and fb caused more issues than standard pages... the issue is that today most websites have some amount of JS content ;)
I still have sync enabled on mine, but I forced places.sqlite to be recreated. I will report back on the performance with this new setup. Cheers,
(In reply to comment #15) > I still have sync enabled on mine, but I forced places.sqlite to be > recreated. I will report back on the performance with this new setup. > > Cheers, Two questions. 1. What build are you using? 2. Having a facepalm moment here but I can't find places.sqlite for my profile. Mind pointing me in the right direction?
Look in about:support and it's the latest Firefox 5: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
OK. I'm using 8.0a1 and still have the issue... though for me also it had surfaced in the 5alpha builds itself... thanks for the tip :)
Did you manage to delete your places.sqlite?
Hey, just found this thread. I'm seeing this bug a TON. The one thing I can add -- that should concern developers -- is that this is a fairly pristine Windows 7 installation. It's on a Macbook via Boot Camp. I did install Windows Security Essentials, but the "Not Responding" freeze still hits me even after I disabled it. I also installed Steam, but that's really about it. Freeze hits even when all extensions and plugins are disabled. Freeze often hits when I'm opening a tags menu in the bookmarks bar, but then again I do that alot, so it might not have anything to do with it. Please fix! FF is essentially unusable like this.
Addendum: FF 5.01 on Windows 7.
(In reply to johncallahan from comment #21) > Addendum: FF 5.01 on Windows 7. FF6 is out, have you tried that? Have you also tried deleting your places.sqlite and letting it rebuild?
I made a video of this bug manifesting itself and spent a couple hours looking through Bugzilla, identifying bug reports about this issue. Video ----- http://www.youtube.com/watch?v=IemvFkFPf4U My description of the bug ------------------------- My description seems to match very well with the current bug reporter's description, but I included more details. - Occurs on Windows 7 Pro, x86 with Fx v6.0.1, v7.0 b2, v8.0 a2 - When the bug manifests itself, first the CPU usage for Fx spikes. firefox.exe's CPU usage surges to almost exactly 50% of my dual core CPU. Just to be clear, the CPU usage spike applies only to firefox.exe and NOT to any of plugin-container.exe child processes. When looking at the process with Process Explorer it's visible that all the CPU usage occurs on a single thread from firefox.exe. A couple of seconds after the CPU spike has begun, all Fx windows freeze. The OS attaches the "Not Responding" text to the title of these windows, they stop repainting themselves and no interaction is possible with them for the remaining duration of the freeze. - The freezes occur frequently, every couple minutes, and last at least a couple dozen seconds, sometimes closer to 2 mins. The frequency and duration of a freeze increase the more tabs are opened and the longer Fx has been running. - After all freezes Fx recovers and works as if nothing happened, until the next freeze - If a web page performs playback of a Flash movie when a freeze occurs, the sound of the movie keeps going as Fx is frozen. If the freeze is exceptionally long, at some moment the movie will also freeze. However, in most cases, the movie keeps playing through the freeze - even though it's not visible, I can only hear it - and doesn't seem to notice that anything is wrong with the browser. - I wasn't able to notice any web pages as being facilitators for these freezes as they seem to occur no matter what pages one happens to be on. I've experienced them with 5 tabs pointing to bugzilla.mozilla.org and 3 others pointing to wikipedia, google and imdb. I've even had one with a single tab opened to "about:blank", but only once. - The freezes also occurs periodically even if there is no user interaction with Fx. I'm editing this in Chrome and had Fx opened in the background without being touched and yet freezing periodically. - The freezes are as frequent as described when there is consistent usage of multiple tabs and when Fx has been opened for some time. I've had them occurring the fastest after about 10 mins since Fx was opened. So they do not occur immediately after Fx is started. - I wasn't able to identify any pattern that would trigger a freeze instantly, on demand Related bugs ------------ #590964, #667264 and #655426 look to me like duplicates of this one. I think #490122 is NOT a duplicate of this one and maybe even not related. I think this is important because it may seem like they are related and #490122 is a pretty major bug. Chronologically, #590964 would be the initial reporting of this bug but I choose to see the current reporting as the most relevant because it contains the most details matching my own experience. However, the dupes also have some interesting information that I combed through and you can read about here. Other bug reports that I was able to detect as strongly related to this one --------------------------------------------------------------------------- #590964, https://bugzilla.mozilla.org/show_bug.cgi?id=590964 - I'm almost certain it's a dupe - Comments 2 & 3 report that on a Mac, similar freezes occur at very exact time intervals. I wasn't able to see this. #655426, https://bugzilla.mozilla.org/show_bug.cgi?id=667264 - I'm almost certain it's a dupe - Comment 3 I think describes a different issue, probably #490122 #667264, https://bugzilla.mozilla.org/show_bug.cgi?id=655426 - I can't determine if it's a dupe. The title of this bug seems to imply that Fx recovers from a freeze but some comments of the original reporter point to the need to kill Fx and restart it #490122, https://bugzilla.mozilla.org/show_bug.cgi?id=490122 - This bug deserves a very special mentioning because it's a big one and seems strongly related to the current bug but after reading most of its comments I concluded that they are actually NOT directly related. #490122 describes a general problem with Fx slowing down a lot and becoming jittery, especially during Flash movie playback.
Additional information about my profile/context I'm only seeing this problem on my home computer, not anywhere else. On this home computer I have only the following two addons installed: Adblock Plus 1.3.9, Xmarks 4.0.2 Also, I have a lot of bookmarks. About 8000. They were screwed up a bit by syncing them between Chrome and Fx with Xmarks, some fields went missing. These freezes occurred before Chrome was in the picture. I introduced it as my main browser on this computer because Fx is simply unusable and I need my bookmarks. I tried to determine if accessing the browser history is the culprit here, as suggested in previous comments, but wasn't able to. However, I wouldn't rule out the possibility that this large number of bookmarks is the root problem.
Given that I found that this was a problem with my places.sqlite, have you tried creating a new profile and NOT syncing with Xmarks to see if it happens for a couple of hours? (In reply to Bogdan Iosif from comment #24) > Additional information about my profile/context > > I'm only seeing this problem on my home computer, not anywhere else. > > On this home computer I have only the following two addons installed: > Adblock Plus 1.3.9, Xmarks 4.0.2 > > Also, I have a lot of bookmarks. About 8000. They were screwed up a bit by > syncing them between Chrome and Fx with Xmarks, some fields went missing. > These freezes occurred before Chrome was in the picture. I introduced it as > my main browser on this computer because Fx is simply unusable and I need my > bookmarks. > > I tried to determine if accessing the browser history is the culprit here, > as suggested in previous comments, but wasn't able to. However, I wouldn't > rule out the possibility that this large number of bookmarks is the root > problem.
Answer to Comment 25: No I'm quite sure this bug is dependent on the context of my current profile since it only appears on my home computer and not on the one from work (who's bookmarks are not synced with home). Since the bug can't be triggered reliably, I would need to just use a new profile for an undetermined amount of time and not have access to my bookmarks (which in my case amounts to nonsense because if I don't have my bookmarks then I don't have anything to do in the browser). Thanks for your suggestion. I'm very willing to help diagnosing this problem and I don't mean any disrespect but I want to do something more relevant with my time than trying steps like turning my computer on/off.
(In reply to Bogdan Iosif from comment #26) Bogdan! Marvellous work on the detailed bug report. I have moved on to 9.0a1 and still face the same issue. Just to give a few more details of my issue: I have two machines - Win XP and Win 7. Both machines are running exactly the same build (to the day since I update both nightly builds on a regular basis). This problem surfaced on my Windows 7 laptop for the first time with exactly the same symptoms as you have described in your analysis. The Windows XP machine was still running flawlessly. After struggling for many days, I finally logged this bug and started looking for a solution, chiefly through trial and error. My first step was to disable Sync. I guessed that since the freeze was periodic in nature it may have something to do with Sync. Next, I proceeded to delete the places.sqlite file but the problem was only slightly alleviated. The freeze was still happening. Finally, as a last resort, I created a fresh profile in FF and never set up sync in this profile. This profile is currently running on my machine and momentarily hangs once in a while. At the same time, throughout all this testing, the Windows XP machine has been working absolutely fine with sync enabled in the default profile. I have never had the need to delete the places.sqlite file either. I occassionally keep going back to the old profile on my Windows 7 machine just to check if there is some improvement in the situation but to no avail yet. I am considering upgrading the status of this bug to CRITICAL. Please comment if you agree or disagree with this.
Another thing I forgot to mention in the previous comment, of late I have been observing some freezing in FF even on the Windows XP but it is notably different in two ways: 1) The duration of hang is much shorter - at most 20-30 seconds 2) Even during the hang, I can see the tab that was open loading the page. Its just that I am not able to interact with the UI for the duration of the freeze but FF kind of remembers the past interaction and reproduces all of it when the program comes out of the freeze. Also, there is no spurt in CPU activity during this freeze as was observed on my Windows 7 machine. Recently, I installed Norton Internet Security 2011 on my Windows 7 machine. The software has a process monitor that checks for processes using inordinate amounts of system resources (CPU and RAM). After this I observed that there are two processes that NIS flags during a FF freeze on Windows 7 in default profile: Host Process for Windows and Plugin-container. I assume the first one is the System Idle Process itself while the second one is the process that hosts the flash plugin and other addons. Bogdan can you please confirm which specific process/thread squats on the system resources during a freeze? Also from your feedback I am gathering that this is a bug specific to Windows 7. Do you think it has something to do with the hardware acceleration used in this OS to paint the FF UI? AFAIK, Win XP uses the basic UI so doesn't have this kind of trouble.
Version: 8 Branch → 9 Branch
Priority: -- → P1
In reply to Comment 27: I can't really say what is the appropriate status as I have no idea what CRITICAL means to Mozilla, if it even means anything when only a handful of users are affected. I can however say that I put my reddest flag on this bug since it made me abandon Fx after 10 years of using and evangelizing Mozilla's products. In reply to Comment 28: - Don't know if it's specific to Win 7 as I don't currently use Fx on any other OS - The main firefox.exe's CPU usage spikes, the CPU usage of any of the child plugin-container.exe processes remains normal during the freeze (already mentioned) - No idea if it's related to HW acceleration but seems unlikely. Something fishy with the bookmarks database seems much more likely to me.
(In reply to Bogdan Iosif from comment #29) I agree with you Bogdan that only a few users seem to be affected but I have a nagging doubt as to the reason behind the selectivity of the bug. I am still trying to find a common factor between all our systems and the only thing that stood out was that everybody was using Windows 7. As mentioned earlier, I am also running Win XP and Ubuntu in separate standalone (not VM) instances with exactly the same builds and Sync set to on. The issue is appearing only in the Win 7 version which brings me back to the point that AFAIK it is only the Win 7 OS that supports hardware acceleration as opposed to the other OSes. There is no other significant difference between the instances used on the other platforms. As for your finding related to an issue with the bookmarks database, since I and koppah are both able to get past the worst of these issues after deleting and rebuilding places.sqlite, I would like to believe that the bookmark issue is a subset of the larger issue where the sqllite driver being used by FF is causing a lockup in the process. My strongest reason to believe this is that when Sync is disabled, all is well. It is noteworthy that Sync accesses the history and bookmarks lists on a regular periodic basis to essentially sync them with all other instances in the Sync profile. Regarding the CRITICAL status, I don't know if we have the authority but it may be worthwhile to raise the status to SHOWSTOPPER if required. Just on an aside, are you able to reproduce this bug in a production build say 6?
I've had this issue for months in production Fx versions, since v4 all the way up to v6.0.1. It's only out of desperation that I tried the latest builds of v7 and v8 (see the exact versions in my Comment 23).
(In reply to Bogdan Iosif from comment #31) > I've had this issue for months in production Fx versions, since v4 all the > way up to v6.0.1. It's only out of desperation that I tried the latest > builds of v7 and v8 (see the exact versions in my Comment 23). Sorry missed that bit in your report. I am surprised there are so few of us experiencing this issue when it is present even in production builds
This is an an exercise in futility. It is to rule out any OTHER issues that may exist on your machine. You do not have to do it for an extended period of time, just enough that you are satisfied that it is or isn't occurring with a clean profile. This is one of the basic steps of troubleshooting recommended by Mozilla: http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting Additionally, have either of you tried to attach a debugger to the process when you see it hang and attached a stack trace? https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg The information from those steps is CRITICAL in helping the developers work out what the issue is. Unfortunately, while it may seem really obvious to you what the issue is at your own computer, the people triaging the bugs don't have the luxury. If you want this fixed, give them as much info as you can! (In reply to Bogdan Iosif from comment #26) > Answer to Comment 25: No > > I'm quite sure this bug is dependent on the context of my current profile > since it only appears on my home computer and not on the one from work > (who's bookmarks are not synced with home). > > Since the bug can't be triggered reliably, I would need to just use a new > profile for an undetermined amount of time and not have access to my > bookmarks (which in my case amounts to nonsense because if I don't have my > bookmarks then I don't have anything to do in the browser). > > Thanks for your suggestion. I'm very willing to help diagnosing this problem > and I don't mean any disrespect but I want to do something more relevant > with my time than trying steps like turning my computer on/off.
Priority: P1 → --
Does anyone know what is the logic behind this bug still being UNCONFIRMED when it has a video showing it in action and multiple reporters?
(In reply to koppah from comment #10) > Created attachment 550204 [details] > koppah stack trace There appear to be 2 instances of firefox.exe running in this stack trace. Please ensure that you close Firefox before starting the steps in -> https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report (In reply to Bogdan Iosif from comment #34) > Does anyone know what is the logic behind this bug still being UNCONFIRMED > when it has a video showing it in action and multiple reporters? The reason this bug is still unconfirmed is that we have no reliable steps to reproduce and no one in Triage/QA has been able to reproduce. Can anyone who is experiencing this issue reproduce with a brand new profile with no extensions enabled? If so, please provide the steps to reproduce the issue.
My Toshiba AMD Athlon-X2 with Windows Vista does exactly the same thing. On my machine it is usually so perfectly periodic that my windows task manager "performance screen" looks like a noisy square wave. The period is 528 seconds and the duty cycle is about 20%. Here, I'll upload a picture: http://brannenworks.com/Gravity/FirefoxBug.png During the 50% usage periods shown above, FF is responsible according to the "processes" window. This occurs running a fresh new FF installation with every extension and plugin disabled. It's possible that uninstalling FF and then downloading it and reinstalling causes it to reinstall plugins and the like from before.
OK. Firefox was killing me, so I switched to Chrome, but I'll try it again and see if I can give you a repro. (In reply to Tim (fmdeveloper) from comment #35) > (In reply to koppah from comment #10) > > Created attachment 550204 [details] > > koppah stack trace > > There appear to be 2 instances of firefox.exe running in this stack trace. > Please ensure that you close Firefox before starting the steps in -> > https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report > > (In reply to Bogdan Iosif from comment #34) > > Does anyone know what is the logic behind this bug still being UNCONFIRMED > > when it has a video showing it in action and multiple reporters? > > The reason this bug is still unconfirmed is that we have no reliable steps > to reproduce and no one in Triage/QA has been able to reproduce. Can anyone > who is experiencing this issue reproduce with a brand new profile with no > extensions enabled? If so, please provide the steps to reproduce the issue.
(In reply to Tim (fmdeveloper) from comment #35) > The reason this bug is still unconfirmed is that we have no reliable steps > to reproduce and no one in Triage/QA has been able to reproduce. Can anyone > who is experiencing this issue reproduce with a brand new profile with no > extensions enabled? If so, please provide the steps to reproduce the issue. I'm ready to assist after everyone is convinced that nobody can reproduce this bug without a more advanced investigation where it now occurs.
(In reply to Tim (fmdeveloper) from comment #35) Tim I understand that you need "reliable steps to reproduce the bug" but that's exactly the point. For those of us facing this issue, there seems to be no apparent reason why it is happening in the first place. FF has shown instances of the bug when only one about:blank tab was open and there are no definitive steps that are triggering the bug. It appears no matter what we are doing at the time, often even if the FF window is not in focus. Anyway, I think that we are only thrashing around the bush with all this. I plan to attach and run WinDbg tonight with FF. If I manage to do that, I'll try to get the crash dump to you. Hopefully that would give you a more significant clue to the issue we are facing.
Priority: -- → P1
Priority: P1 → --
I too have been experiencing the issues reported in this thread with FF6.0.x (on Win7/x64).. and have now just confirmed it still occurs with FF6.0.2 (which is probably to be expected given the I've tried safe mode, a new profile (with no extensions/add-ons), disabling Sync and yet this still occurs. Granted, the frequency of the 'not responding' issue is somewhat less with an empty profile, but as I can't really use FF in my normal manner in this particular environment, I guess this is no surprise. I'm experiencing this on my home PC and my Work PC (both Win7/x64).. but as I've got debugging tools and so on installed at work (along with Process Explorer), I thought I'd just throw in a callstack for when it just occurred a minute ago.. ntoskrnl.exe!KiSwapContext+0x7a ntoskrnl.exe!KiCommitThreadWait+0x1d2 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!KiSuspendThread+0x54 ntoskrnl.exe!KiDeliverApc+0x201 ntoskrnl.exe!KiApcInterrupt+0xd7 mozsqlite3.dll!sqlite3VdbeExec+0xe7e mozsqlite3.dll!sqlite3_step+0xd9 xul.dll!mozilla::storage::stepStmt+0x26 xul.dll!mozilla::storage::AsyncExecuteStatements::executeStatement+0x1d xul.dll!mozilla::storage::AsyncExecuteStatements::executeAndProcessStatement+0x1b xul.dll!mozilla::storage::AsyncExecuteStatements::Run+0x1d9 xul.dll!nsThread::ProcessNextEvent+0x15a xul.dll!nsThread::ThreadFunc+0x88 MOZCRT19.dll!_callthreadstartex+0x48 MOZCRT19.dll!_threadstartex+0x66 kernel32.dll!@BaseThreadInitThunk@12+0xe ntdll.dll!___RtlUserThreadStart@8+0x70 ntdll.dll!__RtlUserThreadStart@8+0x1b Each time the lockup occurs, it lasts for 20-30 seconds. The callstack in the thread taking the bulk of the CPU time is the same. At the same time this thread is locked, the main callstack for firefox.exe is as follows: ntoskrnl.exe!KiSwapContext+0x7a ntoskrnl.exe!KiCommitThreadWait+0x1d2 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!KiSuspendThread+0x54 ntoskrnl.exe!KiDeliverApc+0x201 ntoskrnl.exe!KiCommitThreadWait+0x3dd ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!NtWaitForSingleObject+0xde ntoskrnl.exe!KiSystemServiceCopyEnd+0x13 wow64cpu.dll!CpupSyscallStub+0x9 wow64cpu.dll!Thunk0ArgReloadState+0x23 wow64.dll!RunCpuSimulation+0xa wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrpInitializeProcess+0x17e4 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!_ZwWaitForSingleObject@12+0x15 ntdll.dll!_RtlpWaitOnCriticalSection@8+0x13e ntdll.dll!_RtlEnterCriticalSection@4+0x150 mozsqlite3.dll!winMutexEnter+0xb mozsqlite3.dll!vdbeUnbind+0x2e mozsqlite3.dll!sqlite3_bind_text+0x18 xul.dll!mozilla::storage::`anonymous namespace'::variantToSQLiteT<mozilla::storage::`anonymous namespace'::BindingColumnData>+0x14d xul.dll!mozilla::storage::BindingParams::bind+0x2f xul.dll!mozilla::storage::Statement::ExecuteStep+0x65 xul.dll!nsAnnotationService::HasAnnotationInternal+0xcf xul.dll!nsAnnotationService::ItemHasAnnotation+0x38 xul.dll!nsNavBookmarks::GetFolderReadonly+0x51 xul.dll!NS_InvokeByIndex_P+0x27 xul.dll!XPC_WN_CallMethod+0x6fe mozjs.dll!CallCompiler::generateNativeStub+0xf5 mozjs.dll!js::mjit::ic::NativeCall+0x26 mozjs.dll!js::mjit::EnterMethodJIT+0x30 mozjs.dll!js::mjit::JaegerShot+0x97 mozjs.dll!js::RunScript+0xb3 mozjs.dll!js::Invoke+0x40f mozjs.dll!js::ExternalInvoke+0x16d mozjs.dll!JS_CallFunctionValue+0x4d xul.dll!nsXPCWrappedJSClass::CallMethod+0x87c xul.dll!nsXPCWrappedJS::CallMethod+0x56 xul.dll!PrepareAndDispatch+0xe8 xul.dll!SharedStub+0x16 xul.dll!NS_InvokeByIndex_P+0x27 xul.dll!XPC_WN_CallMethod+0x6fe mozjs.dll!js::mjit::EnterMethodJIT+0x30 mozjs.dll!js::mjit::JaegerShot+0x97 mozjs.dll!js::RunScript+0xb3 mozjs.dll!js::Invoke+0x40f mozjs.dll!js::ExternalInvoke+0x16d mozjs.dll!JS_CallFunctionValue+0x4d xul.dll!nsJSContext::CallEventHandler+0x2e2 xul.dll!nsJSEventListener::HandleEvent+0x11b xul.dll!nsEventListenerManager::HandleEventSubType+0x38 xul.dll!nsEventListenerManager::HandleEventInternal+0x2d2 xul.dll!nsEventTargetChainItem::HandleEventTargetChain+0x1ec xul.dll!nsEventDispatcher::Dispatch+0x441 xul.dll!nsXULCommandDispatcher::UpdateCommands+0x166 xul.dll!CommandDispatcher::Run+0x11 xul.dll!nsContentUtils::AddScriptRunner+0x2a xul.dll!nsGlobalWindow::UpdateCommands+0x98 xul.dll!nsFocusManager::Focus+0x2a6cbb xul.dll!nsFocusManager::SetFocusInner+0x2ce xul.dll!nsFocusManager::SetFocus+0x35 xul.dll!nsEventStateManager::PostHandleEvent+0x2bce79 xul.dll!PresShell::HandleEventInternal+0x189 xul.dll!PresShell::HandlePositionedEvent+0x85 xul.dll!PresShell::HandleEvent+0x21a xul.dll!nsViewManager::HandleEvent+0x38 xul.dll!nsViewManager::DispatchEvent+0x2c2 xul.dll!AttachedHandleEvent+0x4e xul.dll!nsWindow::DispatchEvent+0x36 xul.dll!nsWindow::DispatchWindowEvent+0x13 xul.dll!nsWindow::DispatchMouseEvent+0x257 xul.dll!nsWindow::ProcessMessage+0x4059c0 xul.dll!nsWindow::WindowProcInternal+0xea xul.dll!CallWindowProcCrashProtected+0x2e xul.dll!nsWindow::WindowProc+0x1b USER32.dll!_InternalCallWinProc@20+0x23 USER32.dll!_UserCallWinProcCheckWow@32+0x109 USER32.dll!_DispatchMessageWorker@8+0x3bc USER32.dll!_DispatchMessageW@4+0xf xul.dll!nsAppShell::ProcessNextNativeEvent+0x117 xul.dll!nsBaseAppShell::OnProcessNextEvent+0x283 xul.dll!nsThread::ProcessNextEvent+0xaf xul.dll!mozilla::ipc::MessagePump::Run+0x1aa xul.dll!MessageLoop::RunHandler+0x21 xul.dll!MessageLoop::Run+0x15 xul.dll!nsBaseAppShell::Run+0x34 xul.dll!nsAppShell::Run+0x42 xul.dll!nsAppStartup::Run+0x1e xul.dll!XRE_main+0xe00 firefox.exe!wmain+0x34c firefox.exe!__tmainCRTStartup+0x152 kernel32.dll!@BaseThreadInitThunk@12+0xe ntdll.dll!___RtlUserThreadStart@8+0x70 ntdll.dll!__RtlUserThreadStart@8+0x1b I hope this information is useful in tracking down the root cause. Although I'm not able to construct repro steps, I'm happy to try to get other data during my spare time, if this would be useful. I'd hate to have to move away from FF, but this is relatively serious to me in terms of it affecting my day-to-day work (which involves a lot of browser-based tasks). Regards, Dean
Additional points: Personally, I'm only seeing FF enter this 'not responding' state when moving between sites via clicking of bookmarks. Which maybe ties up with the nsNavBookmarks entry in the callstack above. Off it goes to fetch some data from some SQL database, and then something goes wrong? I've not downloaded the FF source for 6.0.2 yet, but I wonder if there's a timeout for mutex acquisition that's set to 20/30 seconds or thereabouts that's responsible for the return to activity - and note that when this does happen on clicking a bookmark, the actual navigation to the bookmark *does not complete*. FF stays on the current site/page. Indicating that the process of dealing with the bookmark navigation request has failed in some way. Thanks, Dean
Actually, I just re-read Koppah's post earlier about the History menu. Looks like I can get this lockup whenever I try opening it. At this point, I get the following callstack. ntoskrnl.exe!KiSwapContext+0x7a ntoskrnl.exe!KiCommitThreadWait+0x1d2 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!KiSuspendThread+0x54 ntoskrnl.exe!KiDeliverApc+0x201 ntoskrnl.exe!KiApcInterrupt+0xd7 mozsqlite3.dll!sqlite3VdbeExec+0xb7a mozsqlite3.dll!sqlite3_step+0xd9 xul.dll!mozilla::storage::stepStmt+0x26 xul.dll!mozilla::storage::Statement::ExecuteStep+0xaf xul.dll!nsNavHistory::ResultsAsList+0x4f xul.dll!nsNavHistory::GetQueryResults+0x1ac xul.dll!nsNavHistoryQueryResultNode::FillChildren+0x5c xul.dll!nsNavHistoryQueryResultNode::OpenContainer+0x2e xul.dll!nsNavHistoryContainerResultNode::SetContainerOpen+0x48 xul.dll!NS_InvokeByIndex_P+0x27 xul.dll!XPCWrappedNative::CallMethod+0x57b xul.dll!XPC_WN_GetterSetter+0xe23 xul.dll!nsIDOMNode_GetParentNode+0xdf xul.dll!nsScriptSecurityManager::CheckPropertyAccessImpl+0x22e So, in this case the main thread has locked up, although curiously the same calls to mozsqlite3.dll!sqlite3VdbeExec and mozsqlite3.dll!sqlite3_step that my earlier bookmark navigation callstacks indicate (although in that case, the calls are taking place in a separate thread, and there's a difference in sqlite3_step function offset going on). Anyhoo.. hope this stuff helps. Dean
I'd suggest that those seeing Hangs within "mozsqlite3.dll!sqlite3" should check if their Places File is sane anymore. https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ Addons like "Xmarks" are known to cause Corruption. And a corrupted Places File is known to cause Symptoms like mentioned here ("Hangs").
The "hang" occurred about 5 minutes into the debug. Tried multiple times with same result. this was a fresh install without sync so there are no plugins, no bookmarks, no history.
(In reply to XtC4UaLL [:xtc4uall] from comment #43) > I'd suggest that those seeing Hangs within "mozsqlite3.dll!sqlite3" should > check if their Places File is sane anymore. I just ran the suggested add-on in Deep Clean mode, and no problems were found. When I deleted/rebuilt my profile (as mentioned in my earlier post), all I did afterwards was re-configure Firefox Sync (to get my bookmarks back - I don't sync my history). I don't use 'Xmarks' or any other 3rd-party bookmark applications. And after rebuilding my profile, I had these 'not responding' moment occur prior to installing/enabling any add-ons. Thanks, Dean
I've just found that setting firefox.exe's priority to "Below Normal" prevents it from locking up. It still shows periodic high levels of resource utilization. At the same time I've got "Windows Task Manager" running, and "Windows Media Player" running a CD. If turning off Windows Media Player changes the behavior I'll update.
This is still occurring in Firefox 7, and we really now have enough data that a dev could pick this up. It's a pity that this widespread bug is still active with no resolution. :-(
(In reply to koppah from comment #48) > This is still occurring in Firefox 7, and we really now have enough data > that a dev could pick this up. It's a pity that this widespread bug is still > active with no resolution. :-( It's out of our control. I think the truth is that Fx is not well enough built so that it can catch context information about this problem where/when it happens. So there is nothing very technical to report. So Fx devs won't reproduce/investigate. Plus, the problem is not big enough to affect Mozilla's public image. Conclusion? We're out of luck and must find a solution on our own. I fully understand your frustration but you must realize that there's a very slim chance for this problem to be solved in the near future. I recommend the same solution I've found to keep myself sane: Chrome. I've switched since reporting on this issue and I can tell you that it has its pluses even though it's guaranteed you'll miss things from Fx, especially if you're a power user. If you'll still miss Fx in the future, get the newest version every 3-6 months and see if the problem magically disappeared. This is what I do. HTH.
Yeah, but the technical aspect IS there: It looks like something is blocking the UI thread by a call to the SQLite update function...
(In reply to koppah from comment #50) > Yeah, but the technical aspect IS there: It looks like something is blocking > the UI thread by a call to the SQLite update function... Yes. The places database removal fixes the problem for some: https://support.mozilla.com/en-US/questions/862445 For others, it's the plugin update (another bug): https://support.mozilla.com/en-US/questions/871496
Component: General → Bookmarks & History
QA Contact: general → bookmarks
Summary: Frequent Firefox freeze and "Not responding" → Frequent Firefox freeze and "Not responding" because the places database becomes corrupted
Version: 9 Branch → Trunk
This may be related to the discussion in bug 686025.
Depends on: 686025
People seeing the hangs, may you please install https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ and run the "Expire" task. Does that improve things?
you may also set browser.taskbar.lists.recent.enabled and browser.taskbar.lists.frequent.enabled to false as a workaround.
I experience these freezes since a long time and it all resolved after disabling Sync. I saw the blog post, switched back to the profile with Sync, installed places-maintenance, executed expiration, and after some minutes it freezed again. I'm returning back to my "Fast profile" which have the only difference of disabled Sync. It's interesting to note that during the total UI/plugin freeze I can still use the scrollbar to scroll current tab but e.g. arrow keys don't work.
I am currently using the "Fast profile" (essentially the profile with sync disabled) and it is working flawlessly.... leads me to believe the issue is with Sync. hopefully someone from the dev team is listening to this... else what's the point of testing nightly builds?
You guys should comment in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=686025 It sounds like the're investigating a very similar issue.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
No longer depends on: 686025
(In reply to Marco Bonardo [:mak] from comment #53) > People seeing the hangs, may you please install > https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ and run > the "Expire" task. Does that improve things? I must admit this solved my problem. I tried it about a month ago and since then I haven't experienced any more freezes. Not even one. I feel both grateful & lucky. Thank You!
(In reply to Bogdan Iosif from comment #59) > (In reply to Marco Bonardo [:mak] from comment #53) > > People seeing the hangs, may you please install > > https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ and run > > the "Expire" task. Does that improve things? > > I must admit this solved my problem. I tried it about a month ago and since > then I haven't experienced any more freezes. Not even one. Firefox 8 has a stable fix for that issue, so there should be no more need for the manual cleanup once it is released.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: