42401 - Launch desktop icon: Can't read mail on IMAP servers on linuz Freeze 100% CPU Usage

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Christos Cheretakis]

Login to IMAP server, everything's OK.
Click on arrow to expand Inbox. Nothing changes in view, just that tooltips show
correct values, but folders aren't below them
move to toolbar in an active button, folders pane get repainted and everything's
correct.
linux 2000061311

Comment 1

[lchiang]

We need to confirm this.

Comment 2

[Karen Huang]

Today's Linux commercial build 06-15-08-M17 seems bad, it crash right away.
I think I will verify this issue for latter better build....

Comment 3

[Karen Huang]

I went back to yesterday Linux morning commercial build.
It's so weird that all the Inbox and folders not list under the server from the 
folder pane even mouse over toolbar buttons.....

Comment 4

[lchiang]

Karen - ok in the latest builds for you?

Comment 5

[Christos Cheretakis]

It takes too long till it updates, but it does. Now on linux/062808

Comment 6

[Christos Cheretakis]

forget it! I moved the mouse without noticing. Still getting the same thing...

Comment 7

[Karen Huang]

I saw this problem on 06-27-09-M17 Linux commercial build:
It's not only mouse over to the toolbar, no matter where you move you mouse , it 
will repaint the folder pane, thread pane, message body.....this is really 
bad....Adding nsbeta2 for the keywords. Confirm and change bug status to NEW!!

Comment 8

[Karen Huang]

Weird!! This problem is not occurring everytime....

Comment 9

[lchiang]

If the problem does not occur everytime, this bug may not be nsbeta2 worthy.  
Can someone attach a screen shot? 

What are the effects to the user?
1.  Does this happen everytime mail is started and displayed?
2.  Does resizing the folder pane fix this redrawing problem?

Comment 10

[Karen Huang]

Yes. The repaint problem is not occurring everytime, but it did occur sometimes.
Even the repaint problem is not occurring everytime, but it is really strange 
especially after I collapse and expand the folders.....sometimes the mail 
folders will even list under news server.....I feel that there is really a 
refresh problem from the folder pane for Linux platform, this will effect the 
user since sometimes they cannot find the folder to store the messages.....I am 
still trying to narrow down this problem....

Comment 11

[Christos Cheretakis]

I'm getting this all the time.
It does not happen only when moving the mouse over the toolbar, but anytime it
generates a -let's call it that way- important event in the system. What I mean
is, just moving the mouse doesn't update the pane. Moving it over the toolbar
does, moving it over the sidebar's handle does, moving it over the personal
bookmark bar does. Moving it everywhere else on the content page, does nothing.

Comment 12

[Karen Huang]

It used to have problem and workforme for the current build now.
Verified on 06-30-09-M17 commercial build. 
Marking workforme in order to marking as verified.

Comment 13

[Karen Huang]

Oops....Sorry!! I think I mark wrong bug.
Reopening this bug since we are still investigating this bug currently....

Comment 14

[Karen Huang]

xalkina, can you try for today's Linux build again?
If the problem is still occurring, would you please attach a screen shot in this 
bug?

I cannot reproduce this problem for today's 06-30-09-M17 commercial build 
even though I saw this problem on 06-27-09-M17 Linux commercial build.....

Comment 15

[Christos Cheretakis]

This is what happens with 063008:

-when logging in, inbox folder appears opened (it didn't use to)
-opening a folder (that is, to see its subfolders) does nothing
-moving inside a toolbar button does nothing, but moving again out of it
refreshes folders pane
-moving on sudebar's handle also updates pane
-closing a folder does not refresh either
-moving to the sidebar's handle does
-moving into a toolbar button is enough to refresh pane (that is, need not move
out of it as well)

Comment 16

[Kenneth J. Dowling]

This looks like bug 29808 / bug 35921 revisited. If you place another window
over the mail/news window, and then remove it, the mail/news window will update.
All the while, the cpu meter is pegged, just like with those other bug reports.

Comment 17

[Karen Huang]

Sounds like this bug is similar to other bugs (bug 29808 & bug 35921).
But I cannot mark dup as the other bugs since it seemed that bug 35921 
fixed on 05-31-00, but this bug logged on 06-13-00, maybe regression again, I 
will update bug 35921 comments as well.....

Comment 18

[scottputterman]

reassigning to trudelle and cc'ing pavlov.

Comment 19

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix.  Pink is somebody looking at 
Trudelle's bugs?

Comment 20

[Mike Pinkerton (not reading bugmail)]

yes, i am. what makes you think i'm not?

Comment 21

[Mike Pinkerton (not reading bugmail)]

i don't see this with a linux build from 7/6/00. can someone help me duplicate 
it?

Comment 22

[Karen Huang]

I used to be able to reproduce this problem on 06-27-09-M17 commercial build, 
but after that, I cannot reproduce this problem again even from today's Linux 
07-06-08-M17 commercial build...but it seems it is occurring everytime from 
xalkina's machine.....

Comment 23

[Kenneth J. Dowling]

Im still seeing this in todays (07/06/00) build. Im running on redhat 6.1 (with
all updates applied) using imap on localhost.

If the mail folder tree is closed upon opening the mail window, everything is
ok. Clicking open the mail folder tree, everything is still ok. Click on the
INBOX and it goes into this state and stays there.

If the mail folder tree is already open (saved open from a previous session)
when the mail window is opened, it immediately goes into this state as it opens
the INBOX. Again, it stays in this state from that point forward.

If the mail folders are closed when the mail window is brought up, I can still
open the news folders without getting into this state. But as soon as the imap
mail folder is clicked open and I click on the INBOX, that's it.

Comment 24

[Mike Pinkerton (not reading bugmail)]

hmmmm, i really tried hard to duplicate this but i still couldn't. using imap, 
everything works just fine.

can someone w/in nscp dupe this and show me?

Comment 25

[lchiang]

Karen - when you see this problem again, can you contact pinkerton to show him 
the problem on your system?

Comment 26

[Karen Huang]

I have tried to reproduce this problem yesterday, but I couldn't reproduce it 
anymore.
I will keep trying on today's build......

Comment 27

[Karen Huang]

I still cannot reproduce this problem again by using today's respin build 
07-07-10-M17 Linux commercial build.....I have tried many times, but it seems 
it's working fine on my Linux machine.

Comment 28

[Mike Pinkerton (not reading bugmail)]

works for me then

Comment 29

[Kenneth J. Dowling]

The problem seems to be gone with build 2000-07-07-21 that I just downloaded.
It was/is still there with the build I have from yesterday.

Comment 30

[Kenneth J. Dowling]

I take it back. This problem is still there. I launch mozilla from a shell script...

#!/bin/sh
cd
cd mozilla/package
exec ./mozilla $@

If I launch it from a term shell prompt, then all is ok. But if I launch it from
an icon on the gnome desktop, kde, efm, or any other window manager/ desktop
environment that can launch it, the problem exists as stated above.

Keep in mind that this problem is initiated in the mail window only, and only
when opening an IMAP mail file.  Strange...

Comment 31

[Karen Huang]

By using today's Linux 07-11-08-M17 commercial build:

After I switch from kde to Gnome and remove .mozilla directory, I am able to 
reproduce this problem at the first time, I will try to reproduce this again and 
see whether I can reproduce it and narrow down this problem again....

Comment 32

[Karen Huang]

I still cannot reproduce it again, I have tried many times in Gnome & switch 
back to KDE, I still cannot reproduce it.... sigh.

Comment 33

[lchiang]

Ken or Christos?  We can't reproduce this within Netscape.  Are you still seeing 
the problem on the latest build?  If so, we may have to reopen this bug.

Comment 34

[Kenneth J. Dowling]

I'm still seeing it with today's build 2000071408. But again, only if I launch
it from a window manager or desktop. If I launch it from a shell prompt, then I
don't see the problem.

Comment 35

[Karen Huang]

I still cannot reproduce this problem by using the same Linux build as you 
(2000071408), anybody w/in nscp can dupe this problem?

Comment 36

[Karen Huang]

I still cannot reproduce this problem on today's 07-20-08-M17 Linux Commercial 
Build. I think that I am going to Verify as Workforme. Anybody (can reproduce 
this problem) still can reopen this bug -- Please use the latest build 
and provide more detail info/steps as well if this is reproducible.

Comment 37

[Kenneth J. Dowling]

These steps will reproduce the problem every time for me....

Running redhat 6.1 with all updates and helix-gnome (up-to-date) to demonstate.

In my path, I have the following shell script named 'mozilla'
#!/bin/sh
cd
cd mozilla/package
exec ./mozilla $@

Move your .mozilla dir out of the way, so you start fresh.  In a term start up
mozilla by type 'mozilla'. When I first start mozilla I resize the window and
then turn the side bar off (View | My Sidebar). Then I go into preferences and
set cookies for the orginating server only. I also set start page to blank. I
exit preference and then exit mozilla.

Start mozilla back up again. Then "Tasks | Mozilla Mail". Fill in the mail
wizard screens. Imap server: localhost. Save password. Finish up wizard. In the
mail window, turn off the 'My Sidebar'. Then into "Mail and News Account
Settings" Fill in the signature field (/home/kdowling/.signature). Then in
server tab, check mail every 2 minutes. In advanced, imap mail folder "mail/".
Uncheck server supports mailboxes in folders with the same name (or whatever it
says). Ok your way out of the account settings.

Click open the Imap server. Click on Inbox. It connectes, gets all the mail
folders, opens the inbox and all appears ok. Leave the imap tree open and close
the mail/news window. Then exit mozilla.

Start mozilla back up from the term, open mail. It contacts the server, opens
the inbox and all apears ok. Leave the imap tree open and close mail, exit mozilla.

Now create a new gnome launcher on the gnome desktop. Name 'Mozilla'.
Description: Mozilla Browser. Execute 'mozilla'. Save it.

Now double click on the disktop icon. Mozilla starts up. All appears fine, you
can browse, etc, no problems. Now open the mail window. It connects to the imap
server, opens the inbox and then goes into this state where cpu usage goes
through the roof, and the window no longer updates/refreshes properly. Sometimes
is will refresh as the mouse moves over the toolbar buttons. But is surely
messed up from this point on. Close the mail window. The problem continues in
the browser window.

This does it every time here. Works ok from a terminal window, but does not when
launched from the desktop icon.

Comment 38

[Mike Pinkerton (not reading bugmail)]

if _all_ of these steps are required, there is no way this should be beta2+. 
Heck, I'd even mark this 'future' if given the chance.

Comment 39

[Peter Trudelle]

Nearly all of these steps are irrelevant.  I can reduce by just adding a
launcher for the app, and running it from there.  This is the same as if, on the
Mac, running the app from an alias made it unusable.  Even worse in fact, since
on Linux launchers are the only way to have the app appear on the desktop.
reopening, nominating for nsbeta3

Comment 40

[Peter Trudelle]

reassigning to pavlov

Comment 41

[leger]

Putting on [nsbeta2-] radar.

Comment 42

[Peter Trudelle]

nsbeta3+, should be able to run properly when launched from a desktop icon

Comment 43

[Christopher Blizzard (:blizzard)]

Here's a description of what's happening here:

The reason why we aren't getting paints on linux is that all paints are handled
in the idle loop of the mainloop and we never make it back to the idle loop
because there's an event stuck in the event queue.

It also means that after this happens, mozilla pegs the CPU and doesn't ever
come back down.

The event isn't processed because it is on the wrong thread.  The fact that it
happens with an IMAP account might be a clue.  Can anyone reproduce this without
and IMAP account?  Is there a way to tell what the source of a particular event
is?

Comment 44

[Christopher Blizzard (:blizzard)]

adding people who might have a clue about this

Comment 45

[Christopher Blizzard (:blizzard)]

Here's how I can create the problem every time.

First, I made a build using objdir that has debugging disabled and optimization
enabled but still has debugging symbols.

CFLAGS=-g CXXFLAGS=-g ../mozilla/configure --enable-nspr-autoconf 
--enable-optimize --disable-debug

build it.

Then created a launcher on the gnome panel that has a command like this:

/home/blizzard/src/mozilla_dbg/build/dist/bin/mozilla 

and can do debugging with gdb and attaching to the process after its running.  I
can also do printf() debugging.

mmm...race conditions.

Comment 46

[Christopher Blizzard (:blizzard)]

More information for interested parties.\

We are calling nsIAppShell::ListenToEventQueue() from the imap thread.  Since
the event queue is actually created on the imap thread and the events are
processed on the main thread we never actually process the event queue that is
created.  Is this bad?  Is this intended behaviour?

Comment 47

[Brian Ryner (not reading)]

cc'ing mscott too.  Do you know how this part of the imap code is supposed to
work?

Comment 48

[Scott MacGregor]

dougt, bienvenu and I worked this out for imap using the proxy code. imap runs
on it's own thread. necko runs on it's own thread. Events are placed in the imap
event queue by necko (on start requests, ODA events, etc). At the same time,
imap is placing events in the UI thread as it proxies calls over to the UI
thread. We are supposed to be pumping events on the imap event queue. I'm not
sure why in this particular scenario that isn't the case.

It works in general on linux or you wouldn't be able to use imap.

Comment 49

[Christopher Blizzard (:blizzard)]

Here's a stack trace where we try to process the event queue on the UI thread
where the queue is owned by the IMAP thread:


Breakpoint 2, printf (
    format=0x400dbda0 "attemping to process events on the wrong thread\n")
    at printf.c:30
30	printf.c: No such file or directory.
(gdb) up
#1  0x400b83a7 in nsEventQueueImpl::ProcessPendingEvents (this=0x8cdfa98)
    at ../../../mozilla/xpcom/threads/nsEventQueue.cpp:344
Current language:  auto; currently c++
(gdb) where
#0  printf (
    format=0x400dbda0 "attemping to process events on the wrong thread\n")
    at printf.c:30
#1  0x400b83a7 in nsEventQueueImpl::ProcessPendingEvents (this=0x8cdfa98)
    at ../../../mozilla/xpcom/threads/nsEventQueue.cpp:344
#2  0x405db4df in event_processor_callback (data=0x8cdfa98, source=0, 
    condition=GDK_INPUT_READ)
    at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:158
#3  0x405db29d in our_gdk_io_invoke (source=0x8cdfb88, condition=G_IO_IN, 
    data=0x8c300c8) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:58
#4  0x40785afa in g_io_unix_dispatch (source_data=0x8cdfba0, 
    current_time=0xbffff630, user_data=0x8c300c8) at giounix.c:135
#5  0x407871b6 in g_main_dispatch (dispatch_time=0xbffff630) at gmain.c:656
#6  0x40787781 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#7  0x40787921 in g_main_run (loop=0x820aa58) at gmain.c:935
#8  0x406a6b95 in gtk_main () at gtkmain.c:476
#9  0x405db9b0 in nsAppShell::Run (this=0x80f29f8)
    at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:335
#10 0x4039513a in nsAppShellService::Run (this=0x80d03b8)
    at ../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:386
#11 0x804d14e in main1 (argc=1, argv=0xbffff844, nativeApp=0x0)
    at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:913
#12 0x804d546 in main (argc=1, argv=0xbffff844)
---Type <return> to continue, or q <return> to quit---
    at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1093
#13 0x4024d9cb in __libc_start_main (main=0x804d43c <main>, argc=1, 
    argv=0xbffff844, init=0x804a698 <_init>, fini=0x80523d0 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff83c)
    at ../sysdeps/generic/libc-start.c:92
(gdb) up
#2  0x405db4df in event_processor_callback (data=0x8cdfa98, source=0, 
    condition=GDK_INPUT_READ)
    at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:158
(gdb) down
#1  0x400b83a7 in nsEventQueueImpl::ProcessPendingEvents (this=0x8cdfa98)
    at ../../../mozilla/xpcom/threads/nsEventQueue.cpp:344
(gdb) print mEventQueue
$1 = (struct PLEventQueue *) 0x8cdfac0
(gdb) print *mEventQueue
$2 = {name = 0x400dbd2b "Thread event queue...", queue = {next = 0x41600f48, 
    prev = 0x41600f48}, monitor = 0x8cdfb08, handlerThread = 0x8cdf788, 
  type = EventQueueIsMonitored, processingEvents = 0, eventPipe = {0, 0}, 
  notifyCount = 0}

This event queue was added to the list of event queues that should be listened
to by the UI thread, which I thought was a little strange.  Is this normal
behaviour?

Where do you expect those events to be processed.  gtk only has a single place
to process events - the main thread.  On Win32 you can have multiple event
queues running in multiple threads but we just aren't that cool.  Do we expect
that the event that comes in on the IMAP queue is going to be proxied back to
that thread?

Since you have to make sure to run mozilla in a very specific way to trigger
this it sounds like a thread race condition of some kind...

Comment 50

[Doug Turner (:dougt)]

I added a check so that events would not be processed on any thread but the 
owners.  pavlov remove this (do you have that bug number, maybe related).

Comment 51

[Christopher Blizzard (:blizzard)]

I really think that would cause havoc.  Here's what I've found:

NS_IMETHODIMP nsAppShellService::Observe(nsISupports *aSubject,
                                         const PRUnichar *aTopic,
                                         const PRUnichar *)
{
  nsAutoString topic(aTopic);

  NS_ASSERTION(mAppShell, "appshell service notified before appshell built");
  if (topic.EqualsWithConversion(gEQActivatedNotification)) {
    nsCOMPtr<nsIEventQueue> eq(do_QueryInterface(aSubject));
    if (eq)
      mAppShell->ListenToEventQueue(eq, PR_TRUE);
  } else if (topic.EqualsWithConversion(gEQDestroyedNotification)) {
    nsCOMPtr<nsIEventQueue> eq(do_QueryInterface(aSubject));
    if (eq)
      mAppShell->ListenToEventQueue(eq, PR_FALSE);
  }
  return NS_OK;
}

That shouldn't add the event queue to the appshell's list of event queues if the
event queue is not a native event queue.  It should looks something like:

nsCOMPtr<nsIEventQueue> eq(do_QueryInterface(aSubject));
PRBool isNative = PR_TRUE;
  if (eq) {
    eq->IsQueueNative(&isNative);
    if (isNative)  
      mAppShell->ListenToEventQueue(eq, PR_TRUE);

Comment 52

[Christopher Blizzard (:blizzard)]

Attachment: patch

Comment 53

[Christopher Blizzard (:blizzard)]

dougt has the same patch in a different place. :(

Comment 54

[Christopher Blizzard (:blizzard)]

I've been told that danm's fix was to not notify observers if the queue was not
a native queue.  Aren't there other things that a queue observer might want to
do, no matter what kind of queue it is?  The point at which it matters if the
queue is a native queue in the appshell service's observer.  I'm attaching
another patch here.

Comment 55

[Christopher Blizzard (:blizzard)]

Attachment: patch 2

Comment 56

[Christopher Blizzard (:blizzard)]

Also, imap feels really peppy after this patch.  Could just be my imagination,
though.

Comment 57

[Christopher Blizzard (:blizzard)]

I talked to danm on the phone and he seemed to agree that this was a better
solution.

I need someone to test this patch on windows + mac.  Can two lucky contestants
do that for me?

Comment 58

[Brian Ryner (not reading)]

I'll test on windows.

Comment 59

[Christopher Blizzard (:blizzard)]

bryner has this tested on windows

Comment 60

[Dan M]

  An addendum to Scott's comment above -- the imap thread explicitly does not 
want other threads processing its event queue. It uses a monitored event queue 
for that purpose, and it's an error that the gtk appshell is adding monitored 
queues to gdk's list of inputs, which can be serviced on any thread.
  I agree that Chris' (second) patch is a better one than what I was thinking of.
  I am still concerned about a point that Brian brought up: I'm pretty sure a 
modal dialog won't work on a monitored queue. Modal dialogs generated from the 
imap thread want to be tested before this patch is checked in. It might all work 
out: the imap thread could stick, waiting for the modal dialog call to return, 
while the main thread services the dialog. Yeah. Could happen. Wants testing, 
though.
  This should be a no-op on Mac and Windows. Neither of those platforms do 
anything with the event queue message. But just for grins, I'll test on the Mac. 
Soon. Just got called into a meeting.

Comment 61

[Christopher Blizzard (:blizzard)]

Well, the password dialog for IMAP comes up OK.  What's an example of a modal
dialog that could come from the IMAP thread?

Comment 62

[Scott MacGregor]

I don't think we have any modal dialogs that come up from the imap thread. We
always proxy the call back to the UI thread and wait for the UI thread to bring
up the modal dialog and return a result to us.

If you were able to get the password dialog up just fine then you should be okay
on the modal dialog front. 

Comment 63

[Christopher Blizzard (:blizzard)]

Good to know.

Comment 64

[Dan M]

Sorry this took me so long. Chris' patch causes no problems on the Mac -- I 
didn't give it a very thorough shakedown, but I'm confident that the code change 
won't affect the Mac, anyway. But I did try the (modal) Open Web Location dialog, 
and a bout of fetching IMAP mail, complete with modal login dialog. Peachy+.

Comment 65

[Christopher Blizzard (:blizzard)]

This didn't make it into the M17 branch.  Have to add a release note for it for
M17.

Comment 66

[Christopher Blizzard (:blizzard)]

a=vidur.  Will check it in when the tree opens.

Comment 67

[Mike Pinkerton (not reading bugmail)]

ahhhh, make it stop, make it stop!

Comment 68

[Stuart Parmenter]

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

Comment 69

[leger]

Adding leger to cc...keeping an eye on this one :-)

Comment 70

[Christopher Blizzard (:blizzard)]

I checked this in two days ago.  Forgot to update the bug.

Comment 71

[Karen Huang]

By using 08-04-14-M17 Mozilla build:
If based on Christopher Blizzard summary (Can't read mail on IMAP servers on
linuz Freeze 100% CPU Usage). I am able to reproduce this problem on Mozilla
build:
After I open the browser will be fine, but after I open mail. the CPU status
will go up to almost 85-90%:

CPU states: 84.9% user, 15.0% system,  0.0% nice,  0.0% idle
Mem:  128092K av, 111952K used,  16140K free,  75208K shrd,   3016K buff
Swap: 133016K av,    488K used, 132528K free                 55328K cached 

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 1491 khuang    20   0 29232  28M 12508 R       0 89.0 22.8  10:05 mozilla-bin
 
It used to cannot be reproduced this problem on Communical build, I will try to
reproduce from latest M17 Commercial build again.....

Updating the summary to reflect the real problem.

Comment 72

[Karen Huang]

I cannot reproduce this problem on 08-04-14-M17 Commercial build since I don't 
even can launch seamonkey from an icon on my KDE desktop!!

Comment 73

[Karen Huang]

Yes. If based on the reproducible on Mozilla build - this should be a nsbeta2+ 
bug, since after I launch it from an icon on the KDE desktop, the CPU usage will 
go up to almost 85-90%, I still can login to an IMAP mail account and see those 
messages headers displayed on the thread pane, but I cannot see the messages 
displayed on the messages body - which is bad :-(

Comment 74

[Jim Roskind]

Blizzard: I'm having a hard time tying together the symptoms described by Karen
with the patch.  Can you explain?
Jim (trying to piece this all together... and it has a long history) Roskind

Comment 75

[Karen Huang]

Since this problem is only occurring if I launch it from
an icon on the KDE desktop for MOZILLA build, if I launch from a term shell 
prompt, then commercial build & Mozilla build both are ok. Adding "launch from 
desktop icon" on the summary to specify this problem. 
(but still cannot launch from desktop icon for commercial build for reproduce 
this problem...) 

Comment 76

[Christopher Blizzard (:blizzard)]

OK, here's the 30 second summary.  Here's the way to reproduce the problem
effectively:

Create a desktop shortcut in GNOME or KDE and launch it from there.  Open an
IMAP mail account that requires a password that you have not saved.  When the
dialog pops up to prompt you for your password, the CPU will be at 100% and
windows in Mozilla will stop repainting.

I'm guessing that the reason why this happens when you launch it from a desktop
launcher instead of the command line in an xterm is that when you print
debugging output to an xterm it's a lot slower and it might slow the main thread
of the application down enough to reproduce the race condition.

There are two distinct symptoms here:

o Windows don't repaint properly
o CPU is at 100% utilization

Windows not being repainted is actually caused by the CPU being at 100% ( more
on that later. )

The reason that the CPU is at 100% is because one of the event queues that is
processed in gtk's mainloop is being processed on the wrong thread.  That is,
the event queue was created on another thread and you aren't allowed to process
it from any thread except where it was created.

To understand why this is happening it is important to understand that there are
two different kinds of thread queues in Mozilla, 'Native' and 'Monitored.'
Native event queues are queues that use a platform specific notification
mechanism.  The Monitored event queue doesn't have a platform specific
notification mechanism and must be polled for retrieve and process events.  See
http://lxr.mozilla.org/seamonkey/source/xpcom/threads/plevent.h#202 for more
information.

The IMAP thread was creating a Monitored event queue.  When it was created and
activated an observer was notifying the appshell service about it.  The appshell
service was blindly adding that event queue to the list of event queues that the
mainloop would listen for events on.

Whenever an event was posted to that event queue, it would wake up the main
thread to process that event queue.  The main thread tries to process the event
queue and fails since the event queue is not owned by the main thread.  When
processing the event queue fails, no change is made to the event queue and the
main thread is woken up again later to process it again.  Hence the 100% CPU usage.

The solution here was to modify the observer of the event queue, the
nsAppShellService, to add only native event queues to the list of event queues
that it should listen to whenever an event queue was activated.

The painting problem relates to the way that gtk does its painting.  gtk
collects paint requests and only does painting when the mainloop returns to an
idle state.  Since the mainloop wasn't ever returning to an idle state because
there was always work to do in the over-agressive event queue it wasn't ever
doing painting.

Sometimes, the layout engine requests an immediate repaint and gtk will flush
the paint queue before doing that paint.  That is why when you moused over the
toolbars you would see things repaint.

This has been fixed on the tip as of the 3rd of August or so.  It was not
checked into the M17 branch because I couldn't get permission to do so.

I hope this answers everyone's questions.

Comment 77

[Karen Huang]

I logged 47782 for Commercial build only: Cannot launch seamonkey after creating 
a desktop shortcut in Linux GNOME/KDE desktop.

Comment 78

[Christopher Blizzard (:blizzard)]

Just FYI, also checked into the M17 branch.

Comment 79

[Kenneth J. Dowling]

Finally... Thank you Christopher. I don't understand why the netscape personel
have to make it so difficult to get such an important fix checked in.

Comment 80

[leger]

Putting on [nsbeta2+][nsbeta3-] to get verified with new bits.

Comment 81

[Karen Huang]

By using Linux 08-07-04-M17 Mozilla build:

Since I can lunch from the KDE desktop icon for Mozilla build,
Verified this is fixed on Mozilla build -- After I login to IMAP mail account,
the CPU status is back to normal and I can read the messages from the message
body, great fix!! :-)

---------------------------------------------------------------          
CPU states:  9.1% user,  4.4% system,  0.0% nice, 86.4% idle
Mem:  128092K av, 123712K used,   4380K free,  88364K shrd,   2620K buff
Swap: 133016K av,    508K used, 132508K free                 60008K cached
   
 1312 khuang    11   0 37292  36M 13528 R       0  2.9 29.1   1:33 mozilla-bin 

-------------------------------------------------------------------------------            

** But without bug 47782 fix, I don't know whether I can verify on Commercial
build or not? :-( I will try on Commercial build soon......

Comment 82

[Karen Huang]

No. I still cannot verify on Commercial build without bugscape 1873 fix
(bugzilla 47782 moved to bugscape 1873 already). I probably will leave this bug 
as is until bugscape 1873 got fixed in order to verify on Commercial build....

Comment 83

[Karen Huang]

Verified as well on Linux 08-07-12-M17 Mozilla build. 
Result is good too for ONLY Mozilla build - still cannot verify on Commercial 
build....

Comment 84

[Karen Huang]

Finally, bugscape 1873 got fixed by Seth.
Verified on Linux 09-01-08-M18 commercial build, the CPU usage is back to
normal. Marking as verified!!

----------------------------------------------------------------------
CPU states: 10.8% user,  1.3% system,  0.0% nice, 87.7% idle
Mem:  127468K av, 121716K used,   5752K free,  42088K shrd,   2612K buff
Swap: 530104K av,  49312K used, 480792K free                 26624K cached
 
  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 4903 khuang    14   0 36644  35M 15028 R       0  7.7 28.7   0:15 mozilla-bin
-------------------------------------------------------------------------------