Closed Bug 742697 Opened 13 years ago Closed 3 years ago

SMTP connection progress bar causes high CPU usage

Categories

(MailNews Core :: Networking: SMTP, defect)

defect
Not set
normal

Tracking

(thunderbird_esr91 wontfix)

RESOLVED FIXED
98 Branch
Tracking Status
thunderbird_esr91 --- wontfix

People

(Reporter: marek.nos, Assigned: rnons, NeedInfo)

References

Details

(Keywords: perf)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Build ID: 20120312181643 Steps to reproduce: 1) Set SMTP server to one that timeout, particularly my network doesn't allow pings or more specific limitation. The SMTP definitely works outside this network. 2) Try to send an email Actual results: 3) Message that connection to SMTP timeouted 4) CPU usage is raised to 50% (one core) until the message is clicked Expected results: 3) Message that connection to SMTP timeouted 4) CPU usage is standard
(In reply to Marek Nos from comment #0) Found 2 similar bugs: bug 311663 & bug 189738.
Component: General → Networking: SMTP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.smtp
Marek can you follow the instructions at https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg and get us a stack trace of your issue ?
Attached file stacktrace (deleted) —
Running this tool for the first time. Excuse any incompleteness. This is what I got.
Is that SMTP server public so that you could tell us the host name? We do NOT need any username/password. We can try to connect to it and wait for the timeout.
smtp.centrum.cz:25
note: CPU usage is raised right after Thunderbird starts connecting to SMTP server, not after timeout message is shown.
Keywords: perf
Whiteboard: [has stack trace]
nothing useful in that stack trace, unfortunately.
Whiteboard: [has stack trace]
I got the raised CPU usage just after pressing Send, but I assume that is the spinning progressbar about "Connected to server XXX". It was just about 25% of a 3Ghz core. I could not get the timeout from the server. I connected to it but did not provide any password. I let TB hang in the dialog requesting the password. After several minutes I gave a wrong password. The dialog closed and the send failed. But I didn't get any high CPU usage. What should I try next?
Attached image Steps to reproduce (deleted) —
To be correct it took 50% on my machine. Now I checked per core and it took more or less equally around 50% from each core. So maybe its natural load. But the load is there since I clicked send [1], then timeout message appeared. Load was still there until I clicked either cancel sending [2] or OK on timeout message [3] which in turn cancels sending. But when cancel sending [2] is clicked then timeout message is still there, but load drops. So it's definitely not caused by timeout message, but the connecting part, and it takes load (quite high) even timeout message is there. See attached image for more explanation on steps. From user perspective, this SMTP is supposed to be available and should require log in. Don't know why it timeouts for me or if the error is somewhere else. Try at different networks with same result. It might be related to this high load. Secure connection is none, authentication is set to password. C:\Users\Marek Nos>telnet smtp.centrum.cz 25 Connecting To smtp.centrum.cz...Could not open connection to the host, on port 25: Connect failed It does work for you?
Yes, I can connect to the server via telnet. Also TB log file shows it talked to the server. Maybe that is the problem, that you do not even connect to the server and get the timeout. I used a nonexistent server now. I got timeout immediately and the progressbar still spinning. Also notice there is another small progress bar in the bottom right corner of the compose window. So all those animations could be quite heavy, maybe they are redrawing too frequently. I can confirm this part of the bug. Just for reference, what is your CPU?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: SMTP timeout message tops CPU usage → SMTP connection progress bar causes high CPU usage
Intel Core2 duo U9400, 1.4 ghz
I'll see if there aren't too many updates of the progress bar in http://mxr.mozilla.org/comm-central/source/mailnews/compose/content/sendProgress.js.
Assignee: nobody → acelists
(In reply to :aceman from comment #13) > I'll see if there aren't too many updates of the progress bar in > http://mxr.mozilla.org/comm-central/source/mailnews/compose/content/ > sendProgress.js. aceman, what were you able to determine? Perhaps this is similar to what I'm seeing as high CPU with progress meter during stalled imap syncing, and most of the cpu is in Paint http://people.mozilla.com/~bgirard/cleopatra/?1354620938776#report=6210e70a7a1f640f9bcbb57e9af8c95997b58917
Flags: needinfo?(acelists)
My findings are in bug 791535.
Depends on: 791535
Flags: needinfo?(acelists)
FWIW, I see the CPU spike on Linux but can't reproduce on Windows 7...
OS: Windows 7 → All
Hardware: x86_64 → All
This bug still exists. Until the connection timeouts, I get 12-13% CPU load in my i5 macbook.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

David, thanks for reporting your results. Can you retest please and tell us if this reproduces with a curent beta?

If it reproduces, please run the performance profiler:

  1. You must be using Thunderbird 68 or newer - betas from https://www.thunderbird.net/en-US/channel/ or current nightly build from https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
  2. Install profiler add-on into thunderbird 68 (or newer https://www.thunderbird.net/en-US/channel/ ) - get the add-on file from https://github.com/firefox-devtools/Gecko-Profiler-Addon/blob/master/gecko_profiler.xpi?raw=true and in Tools > add-ons click the gear to install add-on from file
  3. Follow instructions at https://profiler.firefox.com/ (videos BASED ON FIREFOX at https://profiler.firefox.com/docs/#/./videos-intro )
  4. Create a profiler URL and post it here.
Flags: needinfo?(mueller8)
  • Updated my thunderbird to the newest Version (Thunderbird 68/Ubuntu)
  • Set my "saved messages" folder to an imap one
  • turned my Internet connection off
  • Pressed Ctrl+S
  • The progressbar went forth and back using 100% of one CPU
  • Re-enabled my internet. The progressbar still goes haywire using 100% of one CPU as the message dialogue telling the message could not be saved is still active.
  • Started the profiler
    The profiler result should be downloadable here: https://perfht.ml/30UuI1F

Do I read the profile correctly that most of the time (80%) is used in the poll() function in libc.so.6 (Linux system C standard library)? That would seem to confirm the theory really the drawing/synchronizing on the screen of the progress bar.
There is also a similar bug specifically for Linux at bug 854093.

Is the disabling of network needed to reproduce the bug or is it only to get the progressbar visible for a extended amount of time to capture the profile?

(In reply to Wayne Mery (:wsmwk) from comment #21)

David, thanks for reporting your results. Can you retest please and tell us if this reproduces with a curent beta?

Wayne, as I wrote several times over several years at several places in this bug tracker:
The problem is easily reproducible, also on Linux, with any TB version (meanwhile including 78.4.2.).
Why is there apparently not a single TB developer trying this himself?

Again: just enter an IP address such as 1.2.3.4 as the server name/address.
Then try fetching emails. Until this timeouts,
the progress bar moves forth and back with significant CPU load (10% of one core on my current Linux machine).

Flags: needinfo?(nl0)

I have experienced this bug for several years on multiple Linux machines.

It just happened to me today on Thunderbird 89.0b1 (beta): sending a message over SMTP hung for several minutes while the progressbar keeps on scanning left and right, eating ~60% CPU on a fast machine.

CPU usage goes away if you do View > toolbar > status bar to remove the status bar?

Flags: needinfo?(bernie)
Assignee: acelists → remotenonsense
Status: NEW → ASSIGNED

The patch stops progress bar on SMTP connection timeout or other errors. For the progress bar during copying operation (usually through IMAP), I don't know how to fix it. Maybe there are other bugs tracking it.

Target Milestone: --- → 98 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/e0962bae9283
Emit stop sending event before prompt failure message to dismiss progress bar. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

Somewhat nice that after nearly 10 years something has been done about this.

Yet I strongly suspect that this "cures" just one of the symptoms of a deeper issue,
namely some busy waiting whenever a network connection is a attempted but the network or the addressed server is (temporarily) unavailable.

See also bug 1107251, bug 683651, bug 562977, and likely several more.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: