351364 - Talkback client uses 100% cpu while submitting

Status: VERIFIED DUPLICATE of bug 210251

(Core Graveyard :: Talkback Client, defect)

Description

[Anko]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060902 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060902 Minefield/3.0a1

Talkback uses 100% of cpu everytime it submits a bug.  Looks to me like some sort of polling is going on?

Reproducible: Always

Steps to Reproduce:
1.Wait for firefox to crash for some reason
2.Talkback asks to submit
3.Talkback uses 100% of cpu.

Comment 1

[Gérard Talbot]

This could well be bug 210251 . See comment #29.

Is the talkback incident submitted? being submitted? Can you report in here the talkback incident id?

Comment 2

[Anko]

(In reply to comment #1)
> This could well be bug 210251 . See comment #29.
> 
> Is the talkback incident submitted? being submitted? Can you report in here the
> talkback incident id?
> 

No the talkback incident isn't submitted as far as I can tell - I'm not sure how to open the talkback client to double check.

It could very well be a dupe, I'm on a low bandwidth connection too.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Look at following URL to find out how to check sent incidient ids:

http://kb.mozillazine.org/Talkback#Getting_an_incident_ID

Comment 4

[Anko]

(In reply to comment #3)
> Look at following URL to find out how to check sent incidient ids:
> 
> http://kb.mozillazine.org/Talkback#Getting_an_incident_ID
> 
I have followed these instructions, there is an incident "in queue" but it has no incident id.
it has the captured at date, and the type "program crash".

edit, copy selected incident id(s) does nothing.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So it looks like that no incidient was sent. Ok. So try to send this manually by chosing "Incidients | Send Queued Incidient(s)". Please take care that you have opened your task manager before sending starts. Take a look at the cpu sheet if it's also at 100% load.

Do you have any proxy server or firewall in your network that could cause such behavior? 

Comment 6

[Anko]

(In reply to comment #5)
> So it looks like that no incidient was sent. Ok. So try to send this manually
> by chosing "Incidients | Send Queued Incidient(s)". Please take care that you
> have opened your task manager before sending starts. Take a look at the cpu
> sheet if it's also at 100% load.
> 
> Do you have any proxy server or firewall in your network that could cause such
> behavior? 
> 
Yeah same thing.  Everytime the sending status window is open cpu usage is at 100% (or close to it).  It says connecting, then receiving, then eventually says  the agent could not connect to the server and i should check proxy settings.

I do not need a proxy to connect to the internet. I am on a dialup connection, behind a NAT box. The connection should only be outbound so this should not interfere.  The firewall is disabled.

Even if the firewall was the problem though, it still shouldn't use so much cpu.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Does the high cpu load only occur for trunk builds? Is it possible to test it with a branch build? You may use a crasher bug to verify the behavior with other builds.

Was the report sent and do you have an incidient id?

Comment 8

[Gérard Talbot]

Anko, everything you said in comment #4 and comment #6 suggests that this is actually bug 210251 (see comment #39 and #62 over there; also comment #70 for explanation: "a bug in the network code for the client-server transactions ... narrowed it down to some sort of timing issue" ).

I'm resolving this as bug 210251

*** This bug has been marked as a duplicate of 210251 ***