Closed Bug 216513 Opened 22 years ago Closed 22 years ago

Freeze when trying to view mail folder sorted by thread

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kalin, Assigned: sspitzer)

References

Details

(Keywords: hang, qawanted, stackwanted)

Attachments

(1 file)

gdb backtrace after the freeze
4.04 KB, text/plain
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030808 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030808 Bug #100827 seems related, although old and MacOS. This works with normal (local,mbox) folders. Server is Courier-IMAP, latest. Everything build on Gentoo linux. Looked at top's output: max CPU, memory usage is stable. Will get a trace with gdb. Reproducible: Always Steps to Reproduce: 1. Open MailNews. 2. Select a any IMAP folder with several MSGs. 3. Click on the icon to sort by thread. Actual Results: Application freezes for more than 15 minutes (didn't wait longer). The only way is to kill it (normal kill -15 works) Expected Results: Show MSGs Threaded. Doesn't occur if there is only one MSG in the folder (or just a few?, need more tests)
Attaching the backtrace log, seems like an deep recurrence, trying to update the window? If there are no MSGs to be threaded (i.e. no "Re:" MSGs), the icon changes and it seems to work (in reality nothing should change, but at least it doesn't freeze). Built is with gtk+-2.2.1 AFAIK. courier-imap 1.7.3
I spend too much time trying to get a debugging version of mozilla, may be I'll waiting for 1.5 to rebuild it again... As far as this bug is concerned, I found a probable workaround in the IMAP server: I disabled "threading". Changed: IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE" To: IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE SORT QUOTA IDLE" in /etc/imapd, and now Mozilla doesn't freeze. But it deasn't sort by threads either :-( If you can call this a workaround...
This may be a dupe of bug 213805.
Yes, it looks as a the same problem in bug #213805 to me. After changing the settings on the server side, as in comment #2, I get freezes sometimes which is really strange. By sometimes I mean: less often than before.
*** Bug 213805 has been marked as a duplicate of this bug. ***
Confirming based on dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 217194 has been marked as a duplicate of this bug. ***
*** Bug 212343 has been marked as a duplicate of this bug. ***
Keywords: hang
I wrote up the dupe bug 217194: (Sorry) http://bugzilla.mozilla.org/show_bug.cgi?id=217194 But it seems I should mention that I use POP mail and get the same problem with 1.5a on i386 running Debian GNU/Linux (Sarge).
it would be really useful if someone that sees this bug could compile a build and get a stacktrace with symbols. or figure out what your mail or profile triggers this bug. does this happen with every folder or only some?
Keywords: qawanted, stackwanted
Summary: Freeze when trying to view IMAP folder threaded → Freeze when trying to view mail folder sorted by thread
I also have this problem -- RH9/1.5a/POP mail. I was going to report it when I found this bug.
This problem is still in RC1. Any hope to get this fixed before 1.5 is released?
Requesting block to alert drivers.
Flags: blocking1.5?
I've rebuilt the current version and tried to reproduce the problem. Result: There was a lot of output on STDOUT/STDERR ###!!! ASSERTION: row count did not change by the amount suggested, check caller : 'rowCount == mRowCount', file nsTreeBodyFrame.cpp, line 1708 Break: at file nsTreeBodyFrame.cpp, line 1708 ###!!! ASSERTION: row count did not change by the amount suggested, check caller : 'rowCount == mRowCount', file nsTreeBodyFrame.cpp, line 1708 Break: at file nsTreeBodyFrame.cpp, line 1708 : : ###!!! ASSERTION: row count did not change by the amount suggested, check caller : 'rowCount == mRowCount', file nsTreeBodyFrame.cpp, line 1708 Break: at file nsTreeBodyFrame.cpp, line 1708 ###!!! ASSERTION: row count changed unexpectedly: 'mRowCount == rowCount', file nsTreeBodyFrame.cpp, line 2178 Break: at file nsTreeBodyFrame.cpp, line 2178 The font "-*-*-medium-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-*-*-*-16-*-*-*-*-*-*-*" does not support all the required character sets for the current locale "C" (Missing character set "ISO8859-1") The font "-*-*-medium-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-*-*-*-16-*-*-*-*-*-*-*" does not support all the required character sets for the current locale "C" (Missing character set "ISO8859-1") The font "-*-*-medium-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-*-*-*-16-*-*-*-*-*-*-*" does not support all the required character sets for the current locale "C" (Missing character set "ISO8859-1") The font "-*-*-medium-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-r-*-*-16-*-*-*-*-*-*-*,-*-*-*-*-*-*-16-*-*-*-*-*-*-*" does not support all the required character sets for the current locale "C" (Missing character set "ISO8859-1") JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAppShellService.quit]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goQuitApplication :: line 40" data: no] nsPluginHostImpl::Observe "quit-application" WARNING: requested removal of nonexistent window , file nsWindowWatcher.cpp, line 951 WEBSHELL- = 3 WEBSHELL- = 2 WEBSHELL- = 1 nsPluginHostImpl::Observe "xpcom-shutdown" WARNING: nsExceptionService ignoring thread destruction after shutdown, file nsExceptionService.cpp, line 189 WEBSHELL- = 0 +++ JavaScript debuging hooks removed. nsPluginHostImpl dtor *** Unloading sample JS components GC Cache: hits: 3530 1206 1358 749 154 314 58 47 51 97 hits: 7564, misses: 2524, hit percent: 74.980179% Please mail if I can help in any way to get this fixed.
Brian, Scott, can you look at the stack on this hang and see if anything can be done for 1.5?
Harald: did you build a 1.5 branch build or a trunk build? can someone that sees this bug try a binary trunk build to see if this bug has been fixed inadvertently on the trunk?
I took the source tar ball of Sep 18th, 19:27 from http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/ , configured it via "configure" without any special arguments, removed my usual /usr/local/mozilla directory, and then I ran dist/bin/mozilla. I switched to the Mail window, and removed the browser window. Next I tried to switch to the threaded view of my Inbox.
Scott, Seth, Bienvenu, if this is a recent regression we should try to get it fixed for 1.5. Who can help?
Mozilla ignores any THREAD server capability. So unless disabling THREAD stuff on the server changes the order in which the server returns messages, I don't see how that could affect the client. Harold, did the problem still happen to you with the 09/18 source?
Sorry for the delay. I am still on a business trip. And I don't have access to a Linux box with all tools and libs installed to rebuild Mozilla at the moment. But I have tried the most recent image grabbed from http://ftp.mozilla.org/pub/mozilla/nightly/2003-09-27-05-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz Seems that the problem is still there: Mozilla got stuck after switching to threaded view. Please note that I am using a very old POP server to download my EMails from. No IMAP. And "Keep messages on server" is switched off. Mozilla gets stuck even when there are no new EMails waiting.
how many messages are in your inbox? If you change the size of the message list before switching to threaded view, does the problem still happen? Is there a scroll bar in the message list pane? The stack trace only has layout calls on it, which makes me think we're just redrawing/reflowing...
My report was marked a dupe, but in my case there were only 30 mesages in my inbox. As long as I didn't try to sort it, all was fine. I've not experienced this bug recently with the latest release, but I can't speak for the reporter of this bug.
There are more than 240 EMails in my Inbox. Yes, there is a scrollbar for the messages list, as well as for the list of folders on the left side. Resizing the message window before switching to threaded view does not help. I would agree that Mozilla gets stuck during a refresh of the window. BTW, my Window Manager is fvwm 2.5.7 . For this test I tried the most recent Mozilla image grabbed from nightly/2003-09-29-13-1.5.
Is it possible that the problem has been fixed for the current 1.6a (Oct03)? I couldn't reproduce it anymore using this version. Downgarding to the most recent 1.5 version (Sep29), and the problem was back. It would be nice if the fix could make it into the final 1.5 release, if its not too late. Regards Harri
it's possible; I don't know - can anyone else verify it's fixed in 1.6?
I checked version 1.5 created today: The problem is in.
Flags: blocking1.5?
I build mozilla 1.5 (on Gentoo linux) yesterday and the problem seems to be gone. Will need a few more days to be 100% sure, but for a few minutes insane click-here-and-there, sorting by thread and something else seems to work both on IMAP and POP3 (i.e. mbox) folders. I am using now (rebuilt) CourierIMAP, not secure connection.
>I checked version 1.5 created today: The problem is in. Do you mean the problem still happens in 1.5 or in 1.6, or that it's fixed in 1.5 or 1.6?
The problem is unresolved in Mozilla 1.5 (released a few days ago). Currently I am running Mozilla 1.6a (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031006), which does not have this problem.
marking fixed, since it's fixed on the trunk. Unfortunately, I don't know what fixed this, so I don't know of any way of getting it fixed in 1.5.x - it's quite possible that it's not a mailnews change that fixed it.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 217194 has been marked as a duplicate of this bug. ***
As I said in comment #27, my built-from-source 1.5 does not have the bug. After several days of stable running, I can say works for me (and I was the initial reporter). Bad that the reason for that fix is unknown, the bug may really reappear some day again. Good that it is fixed now.
*** Bug 215613 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: