User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051005 SeaMonkey/1.1a Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051005 SeaMonkey/1.1a When composing news/email or replying to an existing news/email message the seamonkey-bin process immediately jumps to about 90% cpu per "top". Reproducible: Always Steps to Reproduce: 1.Start SeaMonkey 2.Open Mail/News 3.Compose new message or reply to existing Actual Results: CPU monitor turns red and shows 100% usage. Mail and news messages are delivered with no problem and continued usage is unimpaired. Resources never return to normal. Expected Results: Normal mail/news correspondance without system resources being continually consumed. about:buildconfig Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.4.4 -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe c++ gcc version 3.4.4 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --enable-application=suite --enable-calendar --disable-tests --enable-extensions=default,irc,tasks --without-system-nspr --without-system-jpeg --without-system-zlib --without-system-png --without-system-mng --disable-debug --enable-optimize=-Os --enable-crypto --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --disable-xprint --with-pthreads --enable-canvas --enable-glitz Thinking it might be something in my profile, I made a new profile from scratch. I rebuilt without pthreads, canvas, and glitz. I ran the Mozilla 1.7.12 that came with the distro (slackware 10-2) and did not see the same problem. This has been happening for the past few days CVS builds; checkout finish: Wed Oct 5 10:18:15 EDT 2005. I deleted the entire mozilla tree prior to the last build to be sure there were no artifacts messing things up. I've been compiling with gcc-3.4.4 since 7/15/05. err 20050715 with no other glitches except for an mplayer problem in ltd.h. I did make a debug build but since it didn't crash there was nothing to bt. I'm sure there must be a way to isolate the threads and determine what's happening, but I'd need help with that.

recent intense CPU load also reported in bug 310854, bug 311010, bug 311247

Possibly something broken in general, but here it shows only in mail/news compose. Browser and Mail/News have been open for several hours and show "0" CPU at present.

Here's a partial strace -ff from the runaway process. It took about 15 seconds to generate a 50MB file!

confirmed with linux seamonkey trunk 2005100405. This regressed between trunk builds 2005092901 and 2005093005. I'll attach some stacks.

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

We are seeing a similar problem on OS/2. Supposedly the patch that caused this went on the branch too - is this problem happening on the branch for you?

1.8 Branch is fine for me. So perhaps some interaction with another fix that didn't make the branch.

What a mess. We're ending up with a height 0 treebody. Its width ends up oscillating, and so whether it has horizontal overflow ends up oscillating. Now whenever its overflow changes it dispatches an overflow or underflow event which the tree binding catches... and in said event handler the tree binding changes the node in question (removes or adds a scrollbar). Which changes whether the node is overflowing, etc. So we end up in a cycle handling alternating overflow and underflow events. Now the only reason bug 301411 is involved is that as I said the height is 0. Which means that before the patch to that bug we just ignored some resizes and cut off this cycle.

If we can't figure out why trees are screwing us over here, we should probably just back this part of bug 301411 out -- it's not strictly needed to fix that bug. :(

Works for linux. Thank you.

Comment on attachment 198724 [details] [diff] [review] One possible fix Checked this in on trunk. Leaving the bug open to fix the real underlying issue with trees here...

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

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

better summary

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

Mike can you elaborate on why you plussed this bug for RC1. This bug report is listed as being a trunk bug. I am unable to reproduce this on the branch at all. Downgrading the plus to a ? so the delivery team can evaulate and decide if this is a blocker for the branch. Would be helpful if someone has a test case for the branch to see this on. I'm not able to.

Sorry, the reason I plussed it was because I was concerned that this problem would have some sort of backlash on the branch even though we hadn't seen anything. It bothers me a great deal that a patch has such a bad effect on the trunk and does nothing on the branch...

Frankly, we should probably just take the "one possible fix" patch on the branch...

Although... The reason this broke on trunk is that it's a bad interaction with horizontal scrolling of trees. Since that's not on the branch and doesn't plan to land there, I think we're ok.

This is not reproducible for me in Thunderbird version 1.6a1 (20051010), but was reproducible in builds of a few days ago. Was anything changed? Can anyone confirm this? Also see my comment (#64) in Bug 246909.

See comment 12. Sometimes I wonder why I even bother commenting on bugs... :(

Boris, I read everything you write most carefully :-)

My apologies. I usually do pay attention to comments, but I missed this one somehow, probably due to only skimming this bug after Bug 311369 was marked as duplicate. Sorry for the needless spam. :)

Not sure if this is the exact same bug but i have had sunbird on several occasions run at approximately 40% cpu while minimized and idle and 50% while idle and maximized. I have noticed this behaviour on both winxp and 2000. Even if i quit sunbird and restart sunbird, the problem persists, however, it does not persist after a reboot and wont show up for possibly a couple weeks before i see it again. (i cant reproduce it reliably).

re comment 19: before this makes it to branch there is some evidence that this patch has something to do with bug 322074.

bz, should attachment 198724 [details] [diff] [review] be marked obsolete? (after all, it did check in)