809301 - Thunderbird 17 Beta - MacOS enters STUCK-mode.

Status: RESOLVED INCOMPLETE

(Thunderbird :: Untriaged, defect)

Description

[Knut H. Flottorp]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Steps to reproduce:

Start Thunderbird 17 Beta to test, and run "sudo top" in a Terminal window to study system load and observed the state "Stuck" and a large variation in CPU load.


Actual results:

If you run "sudo top" you will see that the CPU consumption is large for TB17B, and in the "State" column TB enters into "stuck" mode - not "Sleeping" waiting for a resource. The reason may be that it competes with resources with Skype (both use ConnectServices). Evidence of a performance bug is the variation in CPU used.

If this relates to Skype, it may be applicable to all platforms - competing for an network / tcp/ip resource or if it is in the TB code.
The Activity Monitor is not trusted because it lay hands on to much resources but the same variation can be seen here.


Expected results:

Top should report a steady CPU load of 2-3% per sample as it does for TB16. It will then every now and then increase when the network is accessed, and user actions will also cause the CPU ratio to be raised.

A large variation of CPU indicates a competition for resource or one piece of code is waiting for another piece of code to execute, and polling this while waiting for the late thread to complete.

Comment 1

[Bob Clary [:bc] (inactive)]

not security sensitive.

Comment 2

[Knut H. Flottorp]

It may be core security related

Comment 3

[Bob Clary [:bc] (inactive)]

Please do not send comments via mail. Please respond in the bug so that everyone can participate. Personally, I take offense at your email. Please read and follow https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

A high cpu usage or stuck processes do not necessarily imply that a bug need be security sensitive. Security sensitive bugs are only visible to a limited number of people which limits the number of people who can diagnose and triage the issue.

Looking at https://wiki.mozilla.org/Security_Severity_Ratings does not lead me to believe there is anything in this bug which should be hidden to protect our users from exploitation.

Comment 4

[Ludovic Hirlimann [:Usul]]

Can we get either a sample or a stack trace ?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Ludovic Hirlimann [:Usul] from comment #4)
> Can we get either a sample or a stack trace ?

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

Comment 6

[Knut H. Flottorp]

I am sorry, but I no longer use TB, found it unsafe, lost emails and without competent support.

You can email me directly, and I can install TB17 with 30GB+ of emails on it, but I use email in my work, I depend on it and it is no toy. Mac Email may lack a ton of features, but it has not lost any emails, appears stable, and does not hang/ get stuck.

So, my problem is "SOLVED" but I expect yours remain.

Comment 7

[Knut H. Flottorp]

Wayne> The bug is transient, TB threads enters "STALLED" for seconds. I suggest you profile the application to find the various threads and sample over time the state, and then what they wait for. Problems like this is usually a piece of code that is "always" used (e.g. making strlen() on a string that is not nil-terminated). It is not on the stack, in particular if you compete with another application for a shared resource like tcp/ip. Here the "Activity Monitor" provides better tools. 

I have installed Xcode to find some other bugs, and can use these tools on TB, according to my schedule.