Closed Bug 33928 Opened 25 years ago Closed 25 years ago

mailnews hangs on shutdown with 8-bit color

Categories

(MailNews Core :: Backend, defect, P1)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: danm.moz)

Details

(Whiteboard: [PDT+]) 

To reproduce:

1. start "mozilla -mail"
2. open an IMAP folder
3. close the window

Browser process never exists. Even worse:

1. Start mozilla (*without* "-mail")
2. Click the mail icon to open mail
3. Close the mail window
4. The whole browser hangs.

I've verified that it doesn't have anything to do with the password dialog (by 
going to an HTTP auth-required site).
jfrancis mentioned he was seeing this with editor on Mac. For me, "mozilla 
-edit" exits cleanly.
Severity: normal → major
the -edit case i mentioned is different.  It doesn't really hang, it just fails 
to quit.  The edit window closes, but the debug console window never goes away 
and the app doesnt quit.  It doesn't hang, though.

It's also been happening (mac debug) for a long time - not at all a recent 
phenom.

Exit on Mac hang bug has been around for a while, as jfrancis points out.

Waterson - are you seeing this in today's build?  You may be running into bug
http://bugzilla.mozilla.org/show_bug.cgi?id=26653.
Severity: major → critical
i filed 33941 on the mac problem.

It looks like this has to do with your palette settings: 8-bit (256 color mode) 
on WinNT is causing me the grief.

Looks like this is undead bug 7426 again. Should I re-open 7426 and mark this a 
dup? Or should we keep this as a new bug?
Summary: mailnews hangs on shutdown → mailnews hangs on shutdown with 8-bit color
We should probably just use this bug to track the problem since it's already 
open.  As long as you referenced bug 7426, we can always go back to that one for 
the history.
re-assigning to dcone. dcone, this is a dup of 7426 which you own and fixed
before. It seems to have been re-introduced into the build yesterday.
Assignee: selmer → dcone
I did not fix that bug.. I put in the correct measures to get the palette 
working, there is a thread or something that is causing it to hang.. palette 
update messages are being sent to a window, or thread that can not tend to those 
messages.. this is not a palette problem.  Rick.. you know who fixed this last 
time.. can you give this to them.
Assignee: dcone → rpotts
hmmm..unfortunately rick is on vacation for a very long time.  =(

Since my laptop only supports 256 colors, this is keeping me from using the 
prodcut. We need to find somebody besides rpotts to own this bug.
Keywords: beta2, dogfood
perhaps dcone could point us at his previous fix so I could have the slightest 
clue what he's talking about. For example, what file was your fix in, Don? Or is 
your fix irrelevant, somehow?
The bugs that are related are 25979 and 30634.  One of the symptoms of this bug 
is that is you do a ::SelectPallete (..., TRUE), this bug goes away.. but
the correct call is ::SelectPallete(..,FALSE) so the palette that is created for 
the window will be a foreground palette.  OK, so looking into this Rods and I 
found that some events were being sent to a Thread and not being dealt with.. 
that is why it would not quit.. 
I still have bug 25979.. but that deals with the colors not looking correct.
This bug deals with the app not being able to quit... and the ::SelectPalette 
with a TRUE as the background parameter will stop it from happening, but this 
parameter has to be FALSE to get the palettes to work correctly so the 
::SelectPalette(..,TRUE)is just part of the reciepe, and is not the fix.

Rick put the following Comment in bug 25979:

So, here's what I've found out so far...  

Summary:
--------
It appears that the FTP thread *does* create a window even though it has no 
message pump :-(.  On shutdown, the UI thread does a SendMessage() to this 
window (to notify it of a palette change) and deadlocks because the FTP 
thread pool is blocked in PR_Wait().

Dirty Details:
--------------
The FTP connection thread creates an nsEventQueue - This causes an NSPR Event 
Receiver Window to be created.  For some reason that only God knows, the 
*constructor* in nsEventQueue does an Addref().  This artifically bumps the 
reference count so that when the FTP connection is destroyed, the event queue 
remains - along with its associated NSPR Event Receiver Window.

Unfortunately, it appears that in *some* instance the artificial Addref is 
necessary.  Each time a method on a proxy object is invoked, 
nsEventQueueServiceImpl::PushThreadEventQueue(...) is called.  This ACTUALLY 
CREATES A NEW nsEventQueue and associated NSPR Event Receiver Window!!!!!!
After the method has been invoked, PopThreadEventQueue(...) is called and the 
Event Queue is destroyed (and the NSPR Event Receiver Window)...  So, in this 
case the artificial reference is necessary :-(

It's no wonder that proxy objects are slow - they create/destroy a window on 
each invocation!!!!!

Right now I feel like the Sewer Urchin on the Tick, after wading through all 
this mess...

I have no idea (yet) how to unravel the reference counting problem with the 
nsEventQueue, but I hope that once the extra NSPR Event Receiver Window is 
destroyed on the FTP thread, the App will stop deadlocking on shutdown...



thanks, Don, that was very helpful. Cc'ing Dougt. I think one of Rick's comments
is obsolete, at least - I don't think proxy objects create new windows on every
invocation anymore.

rpotts is on vacation for a while, per mscott's comments.  Who should this bug 
be assigned to so that it doesn't get "lost"?  Thanks.
setting from blank to M15 milestone for these bugs affecting mail/news.  If you 
disagree, pls comment and add selmer@netscape.com to cc: list.
Target Milestone: --- → M15
pdt team feels waterson's pain, marking pdt+
Whiteboard: [PDT+]
rpotts is on sabbatical. Back to dcone.
Assignee: rpotts → dcone
I don't understand.. this has nothing to do with me.  Bug 25979 said it solved 
this bug once.. (that bug is now my bug to solve some palette issues with colors 
on win98)  Why did I get this back again?  Rick Potts, DanM or Valeski worked on 
and I thought solved this before.  I only know this because I read the bug 
comments from the last time we did this.  I don't have anything to do with 
events or threads.  I just made a call to ::SelectPalette(,FALSE) which I have 
to do.. and now if a thread is created.. it never goes away because of some 
sort of event handling problem.. and thats why we can't quit.  Dan, do you have 
any Idea who should own this.. you and rick seem to have the best handle on 
whats going on.
Assignee: dcone → danm
Call me if you have questions.
p1
Priority: P3 → P1
imap thread now uses a monitored thread event queue.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: nsbeta2
waterson, is this working for you now?
Keywords: beta2
verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.