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)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

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.
Severity: normal → critical
Windows debug build.
QA Contact: lchiang → suresh
Status: NEW → ASSIGNED
Target Milestone: M7
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.
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.
Yes, removing pref file may help too.
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
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.
*** Bug 7945 has been marked as a duplicate of this bug. ***
Target Milestone: M7 → M8
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.
Nothing special at all.  Let me see if anyone else in my group who is running NT
has this problem.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this works for me now. Can you try it again?
Can someone else try it? I don't have a tree with the running tip, I'm on a
necko landing branch...thanks...
Status: RESOLVED → REOPENED
Target Milestone: M8 → M9
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.
Resolution: FIXED → ---
clearing resolution.
*** Bug 9364 has been marked as a duplicate of this bug. ***
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.
Target Milestone: M9 → M10
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.
*** Bug 11757 has been marked as a duplicate of this bug. ***
Whiteboard: [PR1]
Sounds like this needs to be fixed by PR1, so I added a note to the Status
Whiteboard field
Assignee: mscott → bienvenu
Status: REOPENED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
moving to m11 - still a mystery. I'm going to try playing with thread priority
to see if that has any effect.
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.
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.
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.
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.
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.
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)...
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.
Severity: critical → blocker
Upgrading severity to blocker for mail/news dogfood.
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!
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
Whiteboard: [PR1] → [PR1] This no longer crashes
Assignee: rods → troy
Assignee: troy → rods
I have no idea why this is assigned to me...
Assignee: rods → troy
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.
Blocks: 11091
(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)
Blocks: 14742
Severity: blocker → normal
Target Milestone: M11 → M14
Status: NEW → ASSIGNED
Because there's a workaround checked in to the widget code, I assume this is no
longer a blocker...
mscott or jefft, please verify the workaround
Using 256 colors and running my debug build, the problem indeed went away. I can
close the messenger window without a problem.
No longer blocks: 14742
Assignee: troy → rods
Status: ASSIGNED → NEW
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
moving to M15
reassign to don
Assignee: rods → dcone
Fixed
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I'm able to close messenger now. Marking this as verified.
Status: RESOLVED → VERIFIED
I'm seeing this again: filed bug 33928.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.