Firefox is hanging for me under Linux at shutdown. I verified via backout that this is a regression from bug 401726. This occurs even with a fresh profile. I am not sure why others have not reported this. I am seeing this on an AMD64 bit processor running the official 32-bit nightlies and my own 32-bit builds.

bill, thanks for reporting this. can you attach with gdb and see where it is hanging?

(In reply to comment #1) > bill, thanks for reporting this. > > can you attach with gdb and see where it is hanging? > what gdb commands do you want to see? This is like the second time I have done this and I don;t remember what I did the last time.

> what gdb commands do you want to see? I'm interested in the stack, so the "where" command. you'll have to attach to the firefox process, break (ctrl c) and then do where. you may have to do "info threads" and then "thread x" (where x is the thread number) to get to the main ui thread.

bill, is your personal build debug or optimized?

my personal build is optimized, but I could do a debug build. I need to partially rebuild anyway as I currently have this patch backed out anyway.

I noticed this a few times on Windows too. I could not reproduce it deliberately so I was not very sure.

There will be a lag during the first shutdown after applying that patch, as it removes a large number of records from the database. It shouldn't occur at every shutdown. Are you seeing it for every shutdown?

(In reply to comment #7) > There will be a lag during the first shutdown after applying that patch, as it > removes a large number of records from the database. It shouldn't occur at > every shutdown. Are you seeing it for every shutdown? > Well, I get the hang on the first shutdown with a brand new profile. I have waited 15 minutes before killing it. Should I wait longer? I do not see this issue under windows. People seeing this under windows are reporting it is a regression from a completely different check-in ( bug 401722 ).

You shouldn't be seeing any delay at all with a brand new profile. I experienced about 5 second delay at shutdown the first time w/ 3mos+ of history and 70mb places.sqlite (osx/2ghz/2gb).

(In reply to comment #8) > I have > waited 15 minutes before killing it. On Windows definitely not more than 30-40 seconds or so.

(In reply to comment #3) > > what gdb commands do you want to see? > > I'm interested in the stack, so the "where" command. > > you'll have to attach to the firefox process, break (ctrl c) and then do where. > > you may have to do "info threads" and then "thread x" (where x is the thread > number) to get to the main ui thread. > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 0x00a459df in __pthread_enable_asynccancel () from /lib/libpthread.so.0 (gdb) Quit (gdb) where #0 0x00a459df in __pthread_enable_asynccancel () from /lib/libpthread.so.0 #1 0x00a45e01 in read () from /lib/libpthread.so.0 #2 0xf71fd1eb in nsAppShell::EventProcessorCallback (source=0x8482e98, condition=G_IO_IN, data=0x8456448) at /home/wag/mozilla/trunk/widget/src/gtk2/nsAppShell.cpp:66 #3 0x00be3bad in g_io_channel_unix_get_fd () from /lib/libglib-2.0.so.0 #4 0x00bba442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #5 0x00bbd41f in g_main_context_check () from /lib/libglib-2.0.so.0 #6 0x00bbd985 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #7 0xf71fcd69 in nsAppShell::ProcessNextNativeEvent (this=0x8456448, mayWait=0) at /home/wag/mozilla/trunk/widget/src/gtk2/nsAppShell.cpp:144 #8 0xf721dceb in nsBaseAppShell::DoProcessNextNativeEvent (this=0x8456448, mayWait=0) at /home/wag/mozilla/trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:137 #9 0xf721e13d in nsBaseAppShell::OnProcessNextEvent (this=0x8456448, thr=0x8081fc8, mayWait=0, recursionDepth=0) at /home/wag/mozilla/trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:247 #10 0xf7dd8acd in ?? () #11 0x08456448 in ?? () #12 0x08081fc8 in ?? () #13 0x00000000 in ?? () (gdb) info threads 5 Thread 4113529744 (LWP 9475) 0xffffe405 in __kernel_vsyscall () 4 Thread 4090960784 (LWP 9477) 0xffffe405 in __kernel_vsyscall () 3 Thread 4101450640 (LWP 9513) 0xffffe405 in __kernel_vsyscall () 2 Thread 3959946128 (LWP 9525) 0xffffe405 in __kernel_vsyscall () 1 Thread 4156995280 (LWP 9468) 0x00a459df in __pthread_enable_asynccancel () from /lib/libpthread.so.0 (gdb) thread 1 [Switching to thread 1 (Thread 4156995280 (LWP 9468))]#0 0x00a459df in __pthread_enable_asynccancel () from /lib/libpthread.so.0 (gdb) where #0 0x00a459df in __pthread_enable_asynccancel () from /lib/libpthread.so.0 #1 0x00a45e01 in read () from /lib/libpthread.so.0 #2 0xf71fd1eb in nsAppShell::EventProcessorCallback (source=0x8482e98, condition=G_IO_IN, data=0x8456448) at /home/wag/mozilla/trunk/widget/src/gtk2/nsAppShell.cpp:66 #3 0x00be3bad in g_io_channel_unix_get_fd () from /lib/libglib-2.0.so.0 #4 0x00bba442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #5 0x00bbd41f in g_main_context_check () from /lib/libglib-2.0.so.0 #6 0x00bbd985 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #7 0xf71fcd69 in nsAppShell::ProcessNextNativeEvent (this=0x8456448, mayWait=0) at /home/wag/mozilla/trunk/widget/src/gtk2/nsAppShell.cpp:144 #8 0xf721dceb in nsBaseAppShell::DoProcessNextNativeEvent (this=0x8456448, mayWait=0) at /home/wag/mozilla/trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:137 #9 0xf721e13d in nsBaseAppShell::OnProcessNextEvent (this=0x8456448, thr=0x8081fc8, mayWait=0, recursionDepth=0) at /home/wag/mozilla/trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:247 #10 0xf7dd8acd in ?? () #11 0x08456448 in ?? () #12 0x08081fc8 in ?? () #13 0x00000000 in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 3959946128 (LWP 9525))]#0 0xffffe405 in __kernel_vsyscall () (gdb) where #0 0xffffe405 in __kernel_vsyscall () #1 0x00a434dc in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xf7d10bec in ?? () #3 0x08502f0c in ?? () #4 0x08502f4c in ?? () #5 0xec07f19c in ?? () #6 0x00a43e45 in pthread_getspecific () from /lib/libpthread.so.0 #7 0xf7d11113 in ?? () #8 0x08502f0c in ?? () #9 0x08502f4c in ?? () #10 0x0000ea60 in ?? () #11 0xf7dda35a in ?? () #12 0x039388f4 in ?? () #13 0xf7e354d4 in ?? () #14 0x000003e8 in ?? () #15 0x08749c88 in ?? () #16 0xf7d25468 in ?? () #17 0x00000001 in ?? () #18 0xec07f218 in ?? () #19 0xf7d1186d in ?? () #20 0x08502f08 in ?? () #21 0x0000ea60 in ?? () ---Type <return> to continue, or q <return> to quit--- #22 0x000003e8 in ?? () #23 0x00000000 in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 4101450640 (LWP 9513))]#0 0xffffe405 in __kernel_vsyscall () (gdb) where #0 0xffffe405 in __kernel_vsyscall () #1 0x00a43256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xf7d110ee in ?? () #3 0x09214364 in ?? () #4 0x0938ab30 in ?? () #5 0x00000008 in ?? () #6 0xf4772134 in ?? () #7 0x09214360 in ?? () #8 0x0938ab30 in ?? () #9 0xf477216c in ?? () #10 0x09163a68 in ?? () #11 0xf75b4c28 in ?? () from /home/wag/mozilla/trunk/fx32-obj/dist/bin/components/libstoragecomps.so #12 0x09163a68 in ?? () #13 0xf477216c in ?? () #14 0xf75a0df0 in mozStorageService::FlushAsyncIO (this=0x9214360) at /home/wag/mozilla/trunk/storage/src/mozStorageAsyncIO.cpp:581 #15 0xf75a0df0 in mozStorageService::FlushAsyncIO (this=0x827ec18) at /home/wag/mozilla/trunk/storage/src/mozStorageAsyncIO.cpp:581 #16 0xf75a75bc in mozStorageConnection::Close (this=0x916b6b8) at /home/wag/mozilla/trunk/storage/src/mozStorageConnection.cpp:187 #17 0xf75a7976 in ~mozStorageConnection (this=0x916b6b8) at /home/wag/mozilla/trunk/storage/src/mozStorageConnection.cpp:81 ---Type <return> to continue, or q <return> to quit--- #18 0xf75a7d29 in mozStorageConnection::Release (this=0x916b6b8) at /home/wag/mozilla/trunk/storage/src/mozStorageConnection.cpp:69 #19 0xf63014de in nsCOMPtr<mozIStorageConnection>::assign_assuming_AddRef ( this=0x916421c, newPtr=0x0) at ../../../../dist/include/xpcom/nsCOMPtr.h:568 #20 0xf6314058 in nsCOMPtr<mozIStorageConnection>::assign_with_AddRef ( this=0x916421c, rawPtr=0x0) at ../../../../dist/include/xpcom/nsCOMPtr.h:1246 #21 0xf6314aee in nsCOMPtr<mozIStorageConnection>::operator= (this=0x916421c, rhs=0x0) at ../../../../dist/include/xpcom/nsCOMPtr.h:713 #22 0xf63078b1 in nsUrlClassifierDBServiceWorker::CloseDb (this=0x9164208) at /home/wag/mozilla/trunk/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:1895 #23 0xf7df2721 in ?? () #24 0x09164208 in ?? () #25 0xf4772298 in ?? () #26 0xf7de28ad in ?? () #27 0x09164208 in ?? () #28 0x00000008 in ?? () #29 0x00000000 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 4090960784 (LWP 9477))]#0 0xffffe405 in __kernel_vsyscall () (gdb) where #0 0xffffe405 in __kernel_vsyscall () #1 0x0097bf6c in sched_yield () from /lib/libc.so.6 #2 0xf7d19736 in ?? () #3 0x00000000 in ?? () (gdb) thread 5 [Switching to thread 5 (Thread 4113529744 (LWP 9475))]#0 0xffffe405 in __kernel_vsyscall () (gdb) where #0 0xffffe405 in __kernel_vsyscall () #1 0x00a434dc in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xf7d10bec in ?? () #3 0x08092bec in ?? () #4 0x08092b88 in ?? () #5 0xf52f71fc in ?? () #6 0x00a43e45 in pthread_getspecific () from /lib/libpthread.so.0 #7 0xf7d11113 in ?? () #8 0x08092bec in ?? () #9 0x08092b88 in ?? () #10 0x00003a97 in ?? () #11 0xf7dd2fa6 in ?? () #12 0x08092d70 in ?? () #13 0x00000000 in ?? () (gdb)

bill, thanks for the stack trace. it's your third thread that is interesting here, with mozStorageService::FlushAsyncIO() on the stack. we should not blame nsUrlClassifierDBServiceWorker, even though it is on the stack, as we've had this before. see bug #387830 where we've seen this before. dietrich, if I remember correctly, this happened to us last time when we did a bunch of writes (profile import from ie) and then quit immediately. we fixed it with a transaction. on quit, when we expire history, do we use a transaction?

bill, since you can reproduce this hang, would you be willing to try out a fix?

bill, can you apply this patch and see if you still hang?

Comment on attachment 287196 [details] [diff] [review] patch I'm hoping this fixes things for bill, but I think we want to use transactions either way. note to dietrich, I think we may want to fix those two "XXX" instances, pass PR_FALSE for the second param, but keep the Commit().

The patch did not help. However, I have also found that I can no longer reproduce the issue where it hangs on shutdown using a new profile, either with, without this patch or even using the same build (1031 daily) where I did have a shutdown hang using a new profile. Either I just screwed up, or this was some other random shutdown hang having nothing to do with this issue and I should have tried more than once. II do occasionally get a shutdown hang, presumably due to some race condition somewhere that is an isolated incident). In any event, since it only seems to happen for me (no other reports) and evidently it never really happened with a fresh profile, this would seem to have something to do with some sort of corruption in my places.sqlite file. Is there some utility I can run that validates it? Or is there some debug printing I could put add to figure out what is really going on here? Or, should I just save this file somewhere and start a new places.sqlite file to see if the issue comes back?

I saw this issue on Windows XP last night after updating to the build Gecko/2007110212 Minefield/3.0a9pre from the previous day; I can't reproduce it now. The firefox.exe process was still present for over 25 minutes (!) after closing the browser, consuming 95% CPU. During that time I logged it for a while with Sysinternals' Process Monitor, and it was writing consecutive 1032 byte chunks to places.sqlite-journal, a couple every second. The places.sqlite file is 34 MB in size, created 16 August. The PC is a 600Mhz PIII, which I admit is slow, but not *that* slow; there was free physical memory throughout.

Well, now I don't know what to do with this bug. I noticed when I went to rename the places.sqlite file, that it was much larger than I imagined (~13 MB). So, I decided to just let it run to see if it eventually finished. IT did after about 45 minutes. And now shutdown is back to normal, so I would resolve this as INVALID. The problem with this is that I have been running with only a 14 day history versus the default 180. If it takes over 1/2 hour for 14 days, then wont it take 6-1/2 hours to do 180 days worth of history?

Is there some way to do this incrementally with a time limit? SO it spends at max 5 minutes or so per shutdown on this and then picks up where it left off on next shutdown?

(In reply to comment #15) > (From update of attachment 287196 [details] [diff] [review]) > I'm hoping this fixes things for bill, but I think we want to use transactions > either way. In sqlite, any single write query will automatically start a transaction and automatically commit if it's not being called in a transaction to begin with. This is why I didn't wrap these previously, and possibly why it didn't help Bill. > > note to dietrich, I think we may want to fix those two "XXX" instances, pass > PR_FALSE for the second param, but keep the Commit(). > Yes that sounds right. (In reply to comment #19) > Is there some way to do this incrementally with a time limit? > > SO it spends at max 5 minutes or so per shutdown on this and then picks up > where it left off on next shutdown? > My patch for 332748 does more aggressive expiration during idle time, which will reduce the number of records to expire at shutdown. Also, we could cap the number of writes done in these at shutdown, expiring them over a period of time.

bill / ria / alistair: can you send us (dietrich@mozilla.com or sspitzer@mozilla.com) your places.sqlite file that demonstrates the problem, so that we can debug it?

(In reply to comment #20) > My patch for 332748 does more aggressive expiration during idle time, which > will reduce the number of records to expire at shutdown. Also, we could cap the > number of writes done in these at shutdown, expiring them over a period of > time. > THat seems like an excellent idea. For users upgrading from 2.x to 3.0 it should not be an issue, but for those of us who have been testing nightlies, there is no telling what kind of odd shape our paces.sqlite databases might be in, and how long it might take for this to run to completion.

(In reply to comment #21) > bill / ria / alistair: can you send us (dietrich@mozilla.com or > sspitzer@mozilla.com) your places.sqlite file that demonstrates the problem, so > that we can debug it? > I bet we all finally just waited for it to finish once and never saved the file that caused the issue. :-( I know in my case that I have several computers that I run Firefox on, and the only one that exhibited the problem is the one I usually use for testing, regression range narrowing, or developing patches for bugs. On this system I very often go back and forth between Firefox versions that are very old and recent. SO I go back and forth between various points in the development of the places database. It is quite possible that that is required to end up with a database as screwed up as mine was. I have one other system that is running Minefield that I have not tried a recent build on . If that system has the problem, I will send a copy of the file along. It is also quite possible that trying to narrow down a regression range of another issue will get my Linux system database back in a bad state. Unfortunately I screwed up and did not save the file that demonstrated the issue.

This patch contains Seth's fixes for the transaction args and caps moz_places deletes at 1000 per shutdown. I spent a bunch of time trying to tweak this query, and a couple of other entirely different approaches, but wasn't able to get anything better (yet). The query plan showed that as-is it's taking advantage of an index in for each join, so it's pretty well optimized. The issue is the volume of work: In my test file, that query results in 75000 records being deleted (+ 75000 additional records per each index on moz_places). Capping this to 1000 will instead do the expiration over many shutdowns. This work will be augmented by the idle-time expiration in bug 332748.

I can reproduce this with my 20 MB places.sqlite on Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9a9pre) Gecko/2007110223 Minefield/3.0a9pre. It took almost 20 minutes to process the file on shutdown. It seems to be back to normal again after that. I still have a copy of the file that can be used to reproduce this problem. I tested it in a fresh build with Dietrich's patch, and my Athlon 64 3400+ work for 6 minutes after the first shutdown, and around 1 minute after the following two shutdowns. I'm not sure if all the work on the file is done after that. I will send a copy of the places.sqlite file that demonstrates the problem to Dietrich.

I think I'm hitting this as well, Firefox hangs at shutdown for several minutes (before killing the process) with my main profile (places.sqlite: ~8 MB) since updating from 2007110104 to a 2007110404 build. I see a shutdown time of ~25 sec for a test profile (not a new one, but one exclusively used for testing) with a 130 KB places.sqlite file. I also have copies of places.sqlite for both profiles if necessary.

Comment on attachment 287287 [details] [diff] [review] fix sorry for the delay, dietrich. I think we need a new parameter to ExpireHistoryParanoid() If we call ExpireHistoryParanoid() from OnQuit(), and privacy.sanitize.sanitizeOnShutdown is true (note by default, it is false), and privacy.item.history is true (by default, I think it's true), then we should not have a limit of 1000. In this case, the user has configured firefox to delete all history on shutdown. If we call it from OnQuit() and privacy.sanitize.sanitizeOnShutdown is false or if privacy.item.history is false, we can do your limit of 1000 (or maybe even less?) But if we ExpireHistoryParanoid() from nsNavHistoryExpire::ClearHistory(), we should not have a limit of 1000, as again the user is explicitly asking us to remove all history. do we have a bug about providing some sort of user feedback / not blocking the UI while expiring history? if not, I think we should log one.

(In reply to comment #27) > (From update of attachment 287287 [details] [diff] [review]) > sorry for the delay, dietrich. > > I think we need a new parameter to ExpireHistoryParanoid() > > If we call ExpireHistoryParanoid() from OnQuit(), and > privacy.sanitize.sanitizeOnShutdown is true (note by default, it is false), and > privacy.item.history is true (by default, I think it's true), then we should > not have a limit of 1000. > > In this case, the user has configured firefox to delete all history on > shutdown. > > If we call it from OnQuit() and privacy.sanitize.sanitizeOnShutdown is false or > if privacy.item.history is false, we can do your limit of 1000 (or maybe even > less?) > > But if we ExpireHistoryParanoid() from nsNavHistoryExpire::ClearHistory(), we > should not have a limit of 1000, as again the user is explicitly asking us to > remove all history. thanks seth, good catch. i've added this change. i've also reduced the caps in the problematic cleanup methods to 500. the downside of doing this is that nightly testers w/ large histories will take much longer to catch up (ie: longer until history search and autocomplete starts performing optimally for them). however, given that full processing is taking up to 20 mins for some folks, it's likely worth the wait. > > do we have a bug about providing some sort of user feedback / not blocking the > UI while expiring history? if not, I think we should log one. > I'm working on a general purpose Places progress bar in bug 329736.

> i've also reduced the caps in the problematic cleanup methods to 500. the > downside of doing this is that nightly testers w/ large histories will take > much longer to catch up but your expire-a-little-on-idle patch will fix that. that is going to be good stuff. > I'm working on a general purpose Places progress bar in bug 329736. excellent, thanks.

Comment on attachment 287321 [details] [diff] [review] fix v2 r=sspitzer, thanks dietrich one comment, one nit: 1) nsresult rv = aConnection->CreateStatement(NS_LITERAL_CSTRING( - "DELETE FROM moz_historyvisits WHERE visit_date < ?1 " - "AND (visit_type = ?2 OR visit_type = 0)"), + "DELETE FROM moz_historyvisits WHERE id IN (" + "SELECT id FROM moz_historyvisits WHERE visit_date < ?1 " + "AND (visit_type = ?2 OR visit_type = 0) LIMIT ") + + nsPrintfCString("%d", EXPIRATION_CAP_EMBEDDED) + + NS_LITERAL_CSTRING(")"), getter_AddRefs(expireEmbeddedLinksStatement)); NS_ENSURE_SUCCESS(rv, rv); rv = expireEmbeddedLinksStatement->BindInt64Parameter(0, maxEmbeddedAge); NS_ENSURE_SUCCESS(rv, rv); - rv = expireEmbeddedLinksStatement->BindInt32Parameter(1, mHistory->TRANSITION_EMBED); + rv = expireEmbeddedLinksStatement->BindInt32Parameter(1, nsINavHistoryService::TRANSITION_EMBED); you could add a ?3 and bind your paramenter instead of using nsPrintfCString. Up to you. 2) + printf("ExpireHistoryParanoid(%d)\n", aMaxRecords); nit, remove the printf (or wrap with #ifdef DEBUG)

Comment on attachment 287328 [details] [diff] [review] fix v2.1 r=sspitzer, thanks dietrich seeking approval on your behalf, as this fixes a recently introduced m9 hang-on-shutdown regression.

Checking in toolkit/components/places/src/nsNavHistoryExpire.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryExpire.cpp,v <-- nsNavHistoryExpire.cpp new revision: 1.21; previous revision: 1.20 done Checking in toolkit/components/places/src/nsNavHistoryExpire.h; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryExpire.h,v <-- nsNavHistoryExpire.h new revision: 1.6; previous revision: 1.5 done

(In reply to comment #8) > (In reply to comment #7) > > There will be a lag during the first shutdown after applying that patch, as it > > removes a large number of records from the database. It shouldn't occur at > > every shutdown. Are you seeing it for every shutdown? > > > > Well, I get the hang on the first shutdown with a brand new profile. I have > waited 15 minutes before killing it. Should I wait longer? > > I do not see this issue under windows. People seeing this under windows are > reporting it is a regression from a completely different check-in ( bug 401722 > ). > I found out accidentally that the hang I was talking about was caused by Bug 381795 and it happened only one time, and every time when I switch between builds before and after this bug.

I still have this bug even after the patch release (Build 2007110709). The CPU reach 70% and firefox-bin won't close at all.

I can confirm this behavior on Linux (Fedora 7) with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007110712 Minefield/3.0b2pre CPU goes over 80% for a long time ...

As I said earlier this month, this bug is not fixed. I still have to close Fx within the task manager.

I've been seeing this problem with Beta 1 and having installed Beta 2 today, it's still persisting. Shutdown takes a long while (it varies but seems to be longer when the browser's been up for a long while) and the CPU gets thrashed while it's doing whatever it's trying to do. Running firefox --debug attaches GDB to it but during the time it's thrashing, nothing appears in the output until the point where it actually exits. This is a Linux system running 64-bit AMD, but with the 32-bit Firefox downloaded. I've tried it with both my existing profile and with the profile deleted so it's completely clean. Debug output follows: /usr/local/firefox/run-mozilla.sh -g /usr/local/firefox/firefox-bin MOZILLA_FIVE_HOME=/usr/local/firefox LD_LIBRARY_PATH=/usr/local/firefox:/usr/local/firefox/plugins:/usr/local/firefox::/usr/local/lib:/usr/local/kde/lib:/usr/local/lib DISPLAY=:0.0 DYLD_LIBRARY_PATH=/usr/local/firefox:/usr/local/firefox LIBRARY_PATH=/usr/local/firefox:/usr/local/firefox/components:/usr/local/firefox SHLIB_PATH=/usr/local/firefox:/usr/local/firefox LIBPATH=/usr/local/firefox:/usr/local/firefox ADDON_PATH=/usr/local/firefox MOZ_PROGRAM=/usr/local/firefox/firefox-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger= /usr/bin/gdb /usr/local/firefox/firefox-bin -x /tmp/mozargs.U14054 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/local/firefox3B2/firefox-bin (no debugging symbols found) warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 4143998656 (LWP 14059)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 4141603728 (LWP 14062)] [New Thread 4133211024 (LWP 14063)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (firefox-bin:14059): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so: wrong ELF class: ELFCLASS64 (firefox-bin:14059): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so: wrong ELF class: ELFCLASS64 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 4122663824 (LWP 14064)] [New Thread 4114025360 (LWP 14065)] [New Thread 4105632656 (LWP 14066)] [Thread 4105632656 (LWP 14066) exited] [New Thread 4097239952 (LWP 14067)] [Thread 4097239952 (LWP 14067) exited] [New Thread 4097239952 (LWP 14068)] [New Thread 4105632656 (LWP 14069)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) LoadPlugin: failed to initialize shared library /usr/lib/gnash/libgnashplugin.so [/usr/lib/gnash/libgnashplugin.so: wrong ELF class: ELFCLASS64] LoadPlugin: failed to initialize shared library /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so [/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so: wrong ELF class: ELFCLASS64] [New Thread 4084222864 (LWP 14071)] [New Thread 4075830160 (LWP 14072)] to do: 1) Add first run routine. 2) Mozilla compatibility and install routine. 3) Prefs on new firstrun. 4) Add locales. attributes: CuteMenus2installing flashblock *** e = [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://browser/content/utilityOverlay.js :: getShellService :: line 285" data: no] (firefox-bin:14059): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed (firefox-bin:14059): GLib-GObject-WARNING **: invalid (NULL) pointer instance (firefox-bin:14059): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (firefox-bin:14059): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed (firefox-bin:14059): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed (firefox-bin:14059): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed (firefox-bin:14059): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:2180: invalid unclassed object pointer for value type `GdkScreen' (firefox-bin:14059): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed (firefox-bin:14059): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:2180: invalid unclassed object pointer for value type `GdkScreen' (firefox-bin:14059): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed [Thread 4084222864 (LWP 14071) exited] [New Thread 4084222864 (LWP 14073)] [New Thread 4065360784 (LWP 14129)] [New Thread 4056968080 (LWP 14130)] [Thread 4122663824 (LWP 14064) exited] [Thread 4056968080 (LWP 14130) exited] [New Thread 4056968080 (LWP 14131)] [Thread 4056968080 (LWP 14131) exited] [Thread 4097239952 (LWP 14068) exited] [Thread 4105632656 (LWP 14069) exited] [Thread 4141603728 (LWP 14062) exited] [Thread 4075830160 (LWP 14072) exited] [Thread 4084222864 (LWP 14073) exited] [Thread 4114025360 (LWP 14065) exited] [Thread 4065360784 (LWP 14129) exited] [Thread 4133211024 (LWP 14063) exited] Program exited normally.

oops, I think I was wrong in comment #27, at least partially. see bug #410302

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