User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030915 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030915 After new checkout from cvs that fixed bug 219185 so i can now read email, i note that after periods of inactivity, that the mail client starts spinning chewing up 100% cpu. I have a stripped build (rebuilding with debug symbols) but attaching a debugger shows we're in (gdb) bt #0 0x41ac10d1 in nsMsgLineStreamBuffer::ReadNextLine(nsIInputStream*, unsigned&, int&, unsigned*) () from /usr/local/mozilla/libmsgbaseutil.so Reproducible: Always Steps to Reproduce: 1. Start up mail client, read some emails 2. Leave it in its normal state to check email periodically 3. CPU goes to 100% Actual Results: CPU pinned at 100% Expected Results: CPU not pinned at 100% related perhaps to checkin for bug 218874
*** Bug 219256 has been marked as a duplicate of this bug. ***
what's going on here is that the blocking reads aren't blocking until the connection is established but rather returning success and no data - this causes us to spin very rapidly! Cc'ing Darin for his thoughts about what we should do about this. One possibility is that if the blocking read returns no data, we could sleep for 50 milliseconds or something...I think this only happens when the connection is established. After that, the blocking reads really block.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 131513 [details] [diff] [review] proposed fix readNextLine needs to check for blocking streams, and not return when no data available, but do a blocking read.
fix checked in - please try tomorrow's build.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Looking good with just checkout build. Thanks again David.
You need to log in before you can comment on or make changes to this bug.