Since a few days closing Firefox has become as slow again as in the beginning of the places component. Steps to reproduce: - Import a bookmarks.html and a history.dat file - Open a folder with 10 bookmarks - Close Firefox Between 1.9a1_2006051908 and 1.9a1_2006051912 this changed from 2 seconds to 12 seconds.

What I also see is that Firefox is grubbing hard to load the livemarks. This happens 10 seconds after opening the browser. The CPU goes to 100% for 10 seconds, followed by a lot of writing-to-disk work. When you accidentally close or restart Firefox while it is loading the live bookmarks, Firefox has big problems closing the application. The CPU goes to 100% for a very long time, sometimes a whole minute. In the profile you can see that the parent.lock file is replaced by a bookmarks_history.sqlite-journal file that stays for a very long time.

Does this not happen if you close long after the livemarks have loaded?

No, I don't have the restart problem when the livemarks have stopped loading. Or when I close before they start loading.

(In reply to comment #5) > No, I don't have the restart problem when the livemarks have stopped loading. > Or when I close before they start loading. Oh, great, that's good news. I would be in trouble if it was always slow since I ran out of tricks.

(In reply to comment #2) > What I also see is that Firefox is grubbing hard to load the livemarks. This > happens 10 seconds after opening the browser. The CPU goes to 100% for 10 > seconds, followed by a lot of writing-to-disk work. = Bug 329534

(In reply to comment #7) > This bug is about closing problems, which did not happen (at least not so dramatically) in the days before 19 May. At the moment you can't just close Firefox and throw the application in the recycler. You get at least one or two warnings that it is "in use".

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

The patch for bug 336230 landed during the regression range Ria mentioned in comment 0. See bug 341384 for another bug that deals with mozStorage async IO-ness. That bug seems to have something to do with thread-manager landing, though. Anyway, I'm guessing that disabling places on trunk (bug 353571) will "fix" these issues, but I still think the underlying cause needs to be looked into and resolved.

ria / adam, are you using debug trunk builds, or release?

Seth, I reported bug 341384 when I was using Linux, but I'm using Windows now. That said, I still run current trunk builds (on Windows) with good sized bookmarks file and keep 30 days of history and I haven't noticed any slow shutdowns for a while now.

I'm using Windows nightlies and hourlies. It takes 6 seconds to close Firefox (before the CPU peaks drop).

It takes 10 sec on either Pentium M 1.1GHz with 1Gb or Pentium Celeron 2.8 GHz with 512 Mb to close no-op xulrunner application on first run. CPU usage is 100% during this time. The time drops to 5 sec on consequent runs on both computers. It happens with both xulrunner-1.9a3 and nightly. It is under Linux, have no w32 box to check. If xulrunner is build with --disable-places, it closes instantly. So this is clearly a regression. I have just compiled xulrunner-1.9a3 with --enable-timeline. Feel free to ask, if I can help with testing.

Closing every time takes about 10 minutes! There is almost no big CPU usage, but very long memory leak that often resolves in crash.

Behavior reported in comment #14 changed between 1.9a3 and 1.9a5. Now it exits immediately if 'nsIAppStartip.quit(eForceQuit)' is invoked. If normal 'window.close()' is used, shutdown time is around 2 sec. The latest version tested is 1.9a8pre-20070807. Long delay (at least 10 sec) on shutdown can be caused if a vertice of a reference cycle in native XPCOM objects ever is accessed from javascript. More on this in bug 392294. Since the delay is gone, the underlying reference cycle should have been fixed and this bug looks fixed also.

10 minutes - that is I mentioned, not 10 seconds. It's since few months already when Minefield is closing with a long 10 minutes 300mb memory leak (have 999 days of history). During the closure memory usage just increasing to over 300mb by 200-500kb every second, oftenly crashing at the end.

I get a similar behavior. after I close firefox, the firefox and firefox-bin are still running and using very little memory with no apparent increase in memory or cpu usage. Also ~/.mozilla/firefox/default/places.sqlite and ~/.mozilla/firefox/default/places.sqlite-journal get heavily modified for around 10 minutes until it exits by itself. I asked on irc and I was told places.sqlite-journal is a sign of crash although I didn't see one myself.

If my situation is a different problem, please let me know so I can file a new bug.

(In reply to comment #16) > Now it exits immediately if 'nsIAppStartip.quit(eForceQuit)' is invoked. If > normal 'window.close()' is used, shutdown time is around 2 sec. The latest > version tested is 1.9a8pre-20070807. Delay on normal shutdown with an empty places.sqlite has been reduced to an unnoticeable level (<< 0.1 sec) in 1.9a8 Nice to see progress!

This seems similar to bug 387830. In any case, can this bug still be seen?

My case has had nothing do with profile migration, since it was happening in a XR app. But the underlying issue looks the same. Nevertheless, it is a WFM since 1.9a8

(In reply to comment #22) > My case has had nothing do with profile migration, since it was happening in a > XR app. But the underlying issue looks the same. > > Nevertheless, it is a WFM since 1.9a8 > Seems to be fixed here too on Linux. The firefox-bin process exists very quickly.

Setting blocking-firefox3? since bug 387830 was marked fixed.

If someone's seeing this again, they should get some STR and open a new bug.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv