7426 - can't close windows if 8 bit color depth and ftp or imap threads running.

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect, P3)

Description

[Suresh]

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.

Comment 1

[lchiang]

Windows debug build.

Comment 2

[Scott MacGregor]

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

[Scott MacGregor]

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....

Comment 4

[Suresh]

Scott, I still see the same problem in Today's (6/4/99) windows debug build.

Comment 5

[jefft]

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.

Comment 6

[Suresh]

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??

Comment 7

[jefft]

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.

Comment 8

[lchiang]

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.

Comment 9

[Suresh]

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

[jefft]

Yes, removing pref file may help too.

Comment 11

[Suresh]

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:
<[e-mail]>
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
<[e-mail]>; 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
<[e-mail]>; 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 <[e-mail]>; We
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Sender:
[e-mail]
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Message-ID:
<[e-mail]>
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
<[e-mail]>
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:
[e-mail]
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

[lchiang]

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

[Phil Peterson]

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

Comment 14

[Scott MacGregor]

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

[lchiang]

Nothing special at all.  Let me see if anyone else in my group who is running NT
has this problem.

Comment 16

[David :Bienvenu]

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

[lchiang]

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.

Comment 18

[David :Bienvenu]

this works for me now. Can you try it again?

Comment 19

[Scott MacGregor]

Can someone else try it? I don't have a tree with the running tip, I'm on a
necko landing branch...thanks...

Comment 20

[David :Bienvenu]

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

[lchiang]

clearing resolution.

Comment 22

[Jean-Francois Ducarroz]

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

Comment 23

[leger]

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.

Comment 24

[Scott MacGregor]

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

[David :Bienvenu]

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

Comment 26

[sol]

Sounds like this needs to be fixed by PR1, so I added a note to the Status
Whiteboard field

Comment 27

[David :Bienvenu]

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.

Comment 28

[David :Bienvenu]

moving to m11 - still a mystery. I'm going to try playing with thread priority
to see if that has any effect.

Comment 29

[David :Bienvenu]

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

[David :Bienvenu]

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

[jefft]

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

[David :Bienvenu]

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.

Comment 33

[David :Bienvenu]

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

[rods (gone)]

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.

Comment 35

[Phil Peterson]

Upgrading severity to blocker for mail/news dogfood.

Comment 36

[rods (gone)]

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

[rods (gone)]

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

Comment 38

[troy]

I have no idea why this is assigned to me...

Comment 39

[rods (gone)]

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

[lchiang]

(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

[troy]

Because there's a workaround checked in to the widget code, I assume this is no
longer a blocker...

Comment 42

[Phil Peterson]

mscott or jefft, please verify the workaround

Comment 43

[jefft]

Using 256 colors and running my debug build, the problem indeed went away. I can
close the messenger window without a problem.

Comment 44

[troy]

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

[rods (gone)]

moving to M15

Comment 46

[rods (gone)]

reassign to don

Comment 47

[dcone (gone)]

Fixed

Comment 48

[Suresh]

I'm able to close messenger now. Marking this as verified.

Comment 49

[Chris Waterson]

I'm seeing this again: filed bug 33928.