Closed
Bug 7426
Opened 25 years ago
Closed 25 years ago
can't close windows if 8 bit color depth and ftp or imap threads running.
Categories
(MailNews Core :: Networking, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M15
People
(Reporter: skasinathan, Assigned: dcone)
References
Details
(Whiteboard: [PR1] This no longer crashes)
Couldn't able to close Messenger after reading an imap folder. This is on 6/1/99 debug build. The Steps I did are 1. Start apprunner. 2. Start messenger using Task, Messenger. 3. Clicked on the imap Inbox folder. 4. Read a message. 5. Close Messenger. It does not respond.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M7
Comment 2•25 years ago
|
||
Setting to M7. I haven't been able to reproduce this yet on my debug build but I did see it on Suresh's machine. Adding jefft to cc list.
Comment 3•25 years ago
|
||
I'm still having trouble getting this to happen on my debug build. Suresh, can you try it out again for us the next time you pull the tree? Maybe it decided to go away....
Scott, I still see the same problem in Today's (6/4/99) windows debug build.
I used to have this problem on my home machine but not on my work machine with the same bits. It went away at some point when I applied various NT service packs and VC++ service packs on my home machine. I strongly suspect that this is os and vc++ sepcific related problem. Suresh, can you try to update your system with latest NT & VC++ service packs. You can download them from the microsoft site.
I downloaded latest version of Windows NT ServicePack 5 and VC++6.0 ServicePack 3. I still see the problem on 6/4/99 Windows debug build and 6/7/99 Windows debug build. Any other solution to this problem??
Beats me. It happened on me on my home machine. I don't have the problem any more. Try to delete your mozregistry.dat from your NT directory and see if that helps.
I asked Suresh to try the release build to see if it's a debug build thing or if it's something with his IMAP folders/environment/account.
I see the same problem in windows release build, as Lisa suggested. jefft, deleting mozregistry didn't help me. I think the problem may be in my pref file or some other files may have been corrupted.
Comment 10•25 years ago
|
||
Yes, removing pref file may help too.
Reporter | ||
Comment 11•25 years ago
|
||
I did more testing on this bug. But none of them doesn't help. 1. File | exit option works, but File | Close or clicking on the little X button to close messenger doesn't work. 2. Deleted mozregistry, msf files - doesn't work. 3. Changed my pref file to use a different mail server - doesn't work. 4. Tried a different pref file with just one imap, pop and news - doesn't work. 5. After I read a imap message I am able to send/get message in pop/news folders. But when I try to close messenger it 'freezes'; 6. Did a IMAP Logging to capture the stream. Here is the log. 174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: * OK tintin.mcom.com IMAP4 service (Netscape Messaging Server 4.1 (built Jun 2 1999)) 174[872f820]: nsmail-5:NA:SendData: 1 capability 174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS LANGUAGE STARTTLS XSENDER X-NETSCAPE XSERVERINFO AUTH=PLAIN AUTH=LOGIN 174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: 1 OK Completed 174[872f820]: nsmail-5:NA:SendData: 2 authenticate plain 174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: + 174[872f820]: nsmail-5:NA:SendData: AHFhdGVzdDM3AE5lIXNjLXBl 174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: 2 OK User logged in (no protection) 174[872f820]: nsmail-5:A:SendData: 3 namespace 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * NAMESPACE (("" "/")) (("Shared Folders/User/" "/")) NIL 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 3 OK Completed 174[872f820]: nsmail-5:A:SendData: 4 lsub "" "*" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\NoInferiors) "/" INBOX 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" Drafts 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" "My folder" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" Templates 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/" TinyTest 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" TinyTest/Tiny2 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" TinyTest/TinyLocal 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" TinyTest/tiny1 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/" Trash 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" "Trash/Shared Folders/Goofy one" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/" "Trash/Shared Folders/User/qatest38/bob" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/" qatest37 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 4 OK Completed 174[872f820]: nsmail-5:A:SendData: 5 lsub "" "Shared Folders/User/*" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 5 OK Completed 174[872f820]: nsmail-5:A:SendData: 6 list "" "INBOX" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LIST (\NoInferiors) "/" INBOX 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 6 OK Completed 174[872f820]: nsmail-5:A:SendData: 7 select "Inbox" 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * 24 EXISTS 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * 0 RECENT 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 899281869] 174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 7 OK [READ-WRITE] Completed 174[872f820]: nsmail-5:S-Inbox:SendData: 8 UID fetch 1:* (FLAGS) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 1 FETCH (FLAGS (\Deleted \Seen) UID 73) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 2 FETCH (FLAGS (\Deleted \Seen) UID 74) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 3 FETCH (FLAGS (\Seen) UID 75) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 4 FETCH (FLAGS (\Deleted \Seen) UID 76) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 5 FETCH (FLAGS (\Seen) UID 77) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 6 FETCH (FLAGS (\Seen) UID 79) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 7 FETCH (FLAGS (\Seen) UID 80) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 8 FETCH (FLAGS (\Deleted \Seen) UID 83) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 9 FETCH (FLAGS (\Seen) UID 84) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 10 FETCH (FLAGS (\Seen) UID 86) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 11 FETCH (FLAGS (\Seen) UID 88) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 12 FETCH (FLAGS (\Seen) UID 89) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 13 FETCH (FLAGS (\Seen) UID 90) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 14 FETCH (FLAGS (\Deleted \Seen) UID 91) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 15 FETCH (FLAGS (\Deleted \Seen) UID 92) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 16 FETCH (FLAGS (\Seen) UID 93) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 17 FETCH (FLAGS (\Seen) UID 94) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 18 FETCH (FLAGS (\Seen) UID 95) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 19 FETCH (FLAGS (\Seen) UID 96) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 20 FETCH (FLAGS (\Seen) UID 97) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 21 FETCH (FLAGS (\Seen) UID 98) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 22 FETCH (FLAGS (\Seen) UID 99) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 23 FETCH (FLAGS (\Seen) UID 100) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 24 FETCH (FLAGS (\Seen) UID 101) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 8 OK Completed 174[872f820]: nsmail-5:S-Inbox:SendData: 9 UID fetch 90 (XSENDER UID RFC822.SIZE BODY[]) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 13 FETCH (UID 90 RFC822.SIZE 1073 XSENDER {0} 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: BODY[] {1073} 174[872f820]: nsmail-5:S-Inbox:STREAM:OPEN Size: 1073: Begin Message Download Stream 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Return-Path: <test37@netscape.com> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from netscape.com ([205.217.237.46]) by tintin.mcom.com 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: (Netscape Messaging Server 4.0b2 ) with ESMTP id 0EZ1IOD0.008 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: for <qatest37@tintin.mcom.com>; Wed, 9 Sep 1998 16:31:25 -0700 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from phantom2.mcom.com (phantom2.mcom.com [208.12.40.52]) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: by netscape.com (8.8.5/8.8.5) with ESMTP id QAA04593 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: for <qatest37@netscape.com>; Wed, 9 Sep 1998 16:31:24 -0700 (PDT) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from netscape.com (localhost [127.0.0.1]) by phantom2.mcom.com (8.7.3/8.7.3) with ESMTP id QAA13841 for <qatest37@netscape.com>; We 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Sender: nbaca@netscape.com 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Message-ID: <35F70FFB.4E700375@netscape.com> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Date: Wed, 09 Sep 1998 16:32:11 -0700 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: From: Test37 <test37@netscape.com> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.3 IP32) 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: X-Accept-Language: en 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: MIME-Version: 1.0 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: To: qatest37@netscape.com 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Subject: 4:31 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Content-Type: text/html; charset=us-ascii 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Content-Transfer-Encoding: 7bit 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: <HTML> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 4:31</HTML> 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: ) 174[872f820]: nsmail-5:S-Inbox:STREAM:CLOSE: Normal Message End Download Stream 174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 9 OK Completed
Comment 12•25 years ago
|
||
Interesting. A bug report came from the outside http://bugzilla.mozilla.org/show_bug.cgi?id=7945 with this similar problem. I can reproduce the hang as well on my system.
Comment 13•25 years ago
|
||
*** Bug 7945 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 14•25 years ago
|
||
I talked to Phil about this and we don't think we're going to hold M7 trying to figure this one out. I thought it was only 2 people that it happened for but now I see it happens on Lisa's machine too. Lisa, anything special you're doing to reliably trigger it? Moving to M8.
Comment 15•25 years ago
|
||
Nothing special at all. Let me see if anyone else in my group who is running NT has this problem.
Comment 16•25 years ago
|
||
This happens to me when I click the close corner, but not when I do a File | Exit. It only happens with Imap, not with Pop.
Comment 17•25 years ago
|
||
Yippee. Someone else besides Suresh and I have this problem. And yes, as we reported, File | Exit works fine and this is only on IMAP.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 18•25 years ago
|
||
this works for me now. Can you try it again?
Comment 19•25 years ago
|
||
Can someone else try it? I don't have a tree with the running tip, I'm on a necko landing branch...thanks...
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Target Milestone: M8 → M9
Comment 20•25 years ago
|
||
I'm sorry, this still happens to me at work, but not at home. Moving to m9, though, since there's an easy work-around.
Comment 21•25 years ago
|
||
clearing resolution.
Comment 22•25 years ago
|
||
*** Bug 9364 has been marked as a duplicate of this bug. ***
Comment 23•25 years ago
|
||
Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.
Updated•25 years ago
|
Target Milestone: M9 → M10
Comment 24•25 years ago
|
||
Bienvenu has made some progress on this bug but we still aren't there yet. I'm going to be gone until Monday which will be after M9 has passed (hopefully) so I'm triaging this to M10.
Comment 25•25 years ago
|
||
*** Bug 11757 has been marked as a duplicate of this bug. ***
Comment 26•25 years ago
|
||
Sounds like this needs to be fixed by PR1, so I added a note to the Status Whiteboard field
Updated•25 years ago
|
Assignee: mscott → bienvenu
Status: REOPENED → NEW
Comment 27•25 years ago
|
||
I've spent a lot of time on this. It definitely has to do with our imap threads - if they are convinced to finish with debugger trickery, the window will close. It does not seem to have to do with having an open connection to a socket - if I leave the connection open but get the thread to finish, the window stil closes. After a suggestion from Rick Potts, I tried pumping pending events when the idle thread wakes up, but that did not help. Rick said there can be problems if a thread other than the ui thread creates windows, but I don't think that's happening.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
Comment 28•25 years ago
|
||
moving to m11 - still a mystery. I'm going to try playing with thread priority to see if that has any effect.
Comment 29•25 years ago
|
||
More info - changing thread priorities did not have an effect. I switched to nsIThreads - no difference (except that the default JOINABLE threads causes the hang to persist after the imap part of the thread has finished, because nsIThread keeps threads running in a pool, which seems to be sufficient to cause this problem - this means that the imap code is very unlikely to be the issue because we've cleaned up completely by the point the thread returns to the pool). After debugging some more, I believe that we get in a state that closing the window causes us to start processing windows messages in such a way that processing the messages causes more messages to get put on the windows event queue than we can deal with. I noticed WM_PALETTEISCHANGING messages getting passed faster than we can handle them.
Comment 30•25 years ago
|
||
thanks to a helpful suggestion from Phil, I believe I've isolated this to a problem with WM_PALETTE messages. If I change my color depth to 8 bits == 256 colors, I can reproduce this problem at home. Before I did this, when I close a window, I get the following messages: after close got msg 10 after close got msg 46 after close got msg 47 after close got msg 2 If I change to 256 colors, I get the following wm messages: after close got msg 10 after close got msg 311 after close got msg 310 after close got msg 310 I'm cc'ing you, Rod, because Peter Trudelle said you would be a good person to contact about windows-specific xpfe problems, and I think this is an xpfe problem...which is exposed by having multiple threads running.
Comment 31•25 years ago
|
||
Great work, phil & david. It puzzles me for such a long time why I can reproduce at the early stage but not recently. All because of the color depth change.
Comment 32•25 years ago
|
||
OK, I verified that this problem happens if you get an ftp thread spinning, so it has nothing to do with IMAP. So, I'd like to reassign this to Rod. Rod, please let me know if there's someone else I should assign it to, or if this doesn't make any sense.
Updated•25 years ago
|
Assignee: bienvenu → rods
Status: ASSIGNED → NEW
Summary: Messenger 'freezes' on imap close → can't close windows if 8 bit color depth and ftp or imap threads running.
Comment 33•25 years ago
|
||
If I change the code in nsWindow.cpp to ignore the WM_QUERYNEWPALETTE and WM_PALETTECHANGED messages, this problem goes away. Obviously, that's not the right fix (and I don't know what the fix should be)...
Comment 34•25 years ago
|
||
I'll take a look because it has to do with nsWindow.cpp but I am not sure I am the right guy. I'll see what I can find out.
Updated•25 years ago
|
Severity: critical → blocker
Comment 35•25 years ago
|
||
Upgrading severity to blocker for mail/news dogfood.
Comment 36•25 years ago
|
||
Well, I am at a complete loss here. Are there any super Windows gurus around? Here is a summary: Basically, viewer hangs when using 256 colors and an additional thread has been started (like ftp) and you try to quit or close. If I comment out the WM_QUERYPALETTE code in nsWindow it closes/quits. If I change the last parameter in the SelectPalette from FALSE to TRUE, it closes/quits. If I don't start the additional thread it close/quits. As a stop gap I will be changing the SelectPalette call so the last param is TRUE which may not provide the best viewing experience, but the hanging of the app will go away until we can figure this out. Help! Please someone!
Comment 37•25 years ago
|
||
More info: The viewer is running i have 3 threads (in the thread window), then I click on an FTP link, now I have 6 threads. The viewer window is still active (because I don't get WM_ACTIVATE when I click on the ftp link or when I go to close the window), when I press on the close button (the X in the uper right), the last message to come through is WM_CLOSE and then it hangs. When I stop the debugger it is spinning in the ftp thread. I check the other threads and the nsWindow has stopped at the bottom of the processing method at the line: ::CallWindowProc((WNDPROC)someWindow->GetPrevWindowProc(), hWnd, msg, wParam, lParam); Now, what role the palettes play in this whole threading situation I have no idea. I check the threads, I
Updated•25 years ago
|
Whiteboard: [PR1] → [PR1] This no longer crashes
Updated•25 years ago
|
Assignee: rods → troy
Comment 38•25 years ago
|
||
I have no idea why this is assigned to me...
Updated•25 years ago
|
Assignee: rods → troy
Comment 39•25 years ago
|
||
Please read the mail I sent to you, before I reassigned the bug. Summary: Rick suggested I reassign this to you because I am buried with my bugs and helping Tom P. out. It appears it has as much to do with threading as it does the palette, Rick thought maybe rpotts could help you solve it.
Comment 40•25 years ago
|
||
(sorry for the extra bug notification - this affects mailnews and target milestone is M11 or M12 so I'm just adding to mail beta tracking bug)
Comment 41•25 years ago
|
||
Because there's a workaround checked in to the widget code, I assume this is no longer a blocker...
Comment 42•25 years ago
|
||
mscott or jefft, please verify the workaround
Comment 43•25 years ago
|
||
Using 256 colors and running my debug build, the problem indeed went away. I can close the messenger window without a problem.
Comment 44•25 years ago
|
||
Assigning bug back to you, because with the workaround in place we do shut down (therefore it's not an urgent bug), and it's not a layout issue
Comment 45•25 years ago
|
||
moving to M15
Assignee | ||
Comment 47•25 years ago
|
||
Fixed
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 48•24 years ago
|
||
I'm able to close messenger now. Marking this as verified.
Status: RESOLVED → VERIFIED
Comment 49•24 years ago
|
||
I'm seeing this again: filed bug 33928.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•