Closed Bug 189702 Opened 22 years ago Closed 19 years ago

Problems sending crash incidents with Talkback

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: galen, Assigned: namachi)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

My first 2 reports through talkback worked, now my 3rd report will not connect.
Tried for 3 days]


Reproducible: Always

Steps to Reproduce:
1. send in report
2.
3.

Actual Results:  
unable to connect. Error reports please check proxy settings. Did not setup for
proxy use. Set 'don use automatic proxy settings'. Did not help. Tried conection
after many reboots over 3 days

Expected Results:  
ability to send in reports
talkback.netscape.com  has shown up instead of talkback5.netscape.com
Now working
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
1.3a likes to want to talk to talkback5. That server appears to be unreachable.
Is there a status page for that server or someway to get talkback to use another
talkback server?
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
may have a been a temporary issue as I also had this issue for 1 day using
20030122 build.
Does it now work fine for you ?
I am dropping talkback because of I have yet to see any resolution of talkback
issues and no reference to any status pages for the servers to alert users.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
Galen:  We were switching one of our Talkback servers to a new machine last
week...and that might have been the reason you were unable to submit your
Talkback incidents.  Have you tried again recently?  Also, are you using a
broadband connection or dialup?
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
I still can't submit Talkback data with build 20030125 (Win2k) and 2003012522 on
Linux, I've got 9 TB IDs to submit. I've got broadband access, also tried at
work, same issue; might be the SQL worm from this WE that made AOLTW people to
filter very connection from outside ?
Can you try it again? Just start talkback.exe (for Windows) and try to send them.
Any updates on this problem?  Have people tried with recent builds to submit
Talkback reports?  
I just tried to send a crash with 2003022408, but could not. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Andrew:  Are you connecting through dialup or broadband?  Have you tried to
manually send the incident by clicking the button in the Talkback UI?

Galen:  Regarding your comment #1.  You couldn't have possibly sent your crash
incident through talkback.netscape.com.  That server is for internal Netscape
users and is behind the firewall.   Any external crashes are collected by
talkback5.netscape.com.  So even if the Talkback progress dialog might be
switching between both of those servers, talkback5 is really the only server you
will be talking to.

I am going to try to send incidents from home tonight and see if they go
through.  I have had no problem sending crashes here at work (but as I said
earlier, my crashes are collected by talkback.netscape.com behind the company
firewall).
Oh...I forgot that this was a Windows 98 bug.   I'll try with my Windows 98
machine at home tonight and report back.

Everyone having problems here is using Windows 98, correct?  
Jay, yes, I'm using Windows 98. I'm on a broadband connection (DSL). No firewall
or proxy server. I tried to resend it as you describe, but it failed in the same
way.
Win98 bug? May I suggest that it be mentioned in the known issues.
Yes I am using win98.
Yes TB did report connecting to talkback.netscape.com
This should block 1.3.
Flags: blocking1.3?
Keywords: mozilla1.3, nsbeta1
Summary: won't connect to talkback5.netscape.com → Talkback can't send reports (Windows 9x-only)
I was able to send incidents successfully from home using a Windows 98 machine.
 I have a 144K IDSL connection through a Linksys router using DHCP.  I was not
using any VPN software and tested with MozillaTrunk build 2003022408.

NOTE:  The first incident what was sent did indeed show talkback.netscape.com as
the server it was contacting.  The second incident showed
talkback5.netscape.com.  I need to verify which on of those servers are actually
getting my crashes.
Ok, after digging through my ethereal capture logs, I figured out that although
the Talkback progress dialog says you're connecting to talkback.netscape.com, it
automatically redirects to talkback5.netscape.com before your incident is
actually sent in.

After some more testing, I also experienced some problems submitting incidents
earlier today with my Windows 98 machine.  For a short period of time between
2:15 and 3pm I was unable to send any crashes I submitted.  However, around 3pm
all incidents that were in queue and any new crashes were being sent just fine.
 I wonder if we are facing some sort of load issue during certain times of the day?
well I've tried on several builds over weeks at many different times of day. All
dead.
Not sure if it makes any difference, but Galen, are you using Windows 98 Second
Edition?  My machine was a Win98 SE.
Speaking for myself, I've been using Win 98SE.
using win98 SP1 with all updates. I will try ethereal
After discussing this problem with Shiva, I have come to the understanding that
external users are able to submit incidents to either talkback or talkback5. 
That is why some people see different servers in the progress dialog.

In terms of a workaround, I think I might have found one.  At least for
me...when I had a list of crashes in queue, all I had to do was delete the
oldest incident that was waiting to be sent and try to send the next one
manually.  When I did this last night, all my incidents went through ok.

For those that still have a long list of incidents waiting to send...could you
try this and report back?  Thanks.
would be good to get fixed but not going to block 1.3 for this.
Flags: blocking1.3? → blocking1.3-
Just now I was able to send two Talkback reports. Maybe it is now working? Or
maybe it's sporadic?
We are actively fixing the Talkback submission problem. Please try next few more
days and give us more feedback. For now, I am going to leave this bug to avoid
reporting duplicate bugs. 
Bugs 60968, 167536, and 189702 seem to all be the same.  People have been having
this problem for over two years, and still no resolution.

Contrary to what I said in a previous message, the problem does seem to be with
connecting.  I installed a firewall and watched what was going on, and it never
did successfully make a connection (despite maxing out my modem's upstream
bandwith the entire time...what on earth is it doing?).

If I copy the talkback data and take it into work, it goes through with no
problem the first time I try it, every time.  My work connection is faster but
much more restricted, so that's surprising.  Perhaps this wasn't written with
modem users in mind.  Perhaps the upstream bandwith maxing out shows there is
some flaw in the code, such as it has an unrealistic timeout for connecting and
keeps retrying and retrying, never really giving it a chance to respond.  As
I've said before, once in a blue moon it does work, so the capability is there.

This problem has been there for years, and I bet it's affecting a LOT of people
(how many bother to go into Bugzilla and complain?  Most probably just turn it
off).  I also know that it's not being taken seriously enough to get fixed.  You
have three identical bugs, and nobody's even noticed that.  That shows how
seriously it's taken.  Oh, and all three are still marked as "NEW" even though
one is over two years old.

We've asked for this to get fixed.  I've asked for an alternative method of
sending these (email or uploading) if that can't be done.

I guess it's just time to say if you don't care, then we don't care...time to
turn this feature off.

*** Bug 167536 has been marked as a duplicate of this bug. ***
*** Bug 60968 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
Summary: Talkback can't send reports (Windows 9x-only) → Problems sending crash incidents with Talkback
tbid 19157165,19156892 were not accepted in the client even though the same
incident was recorded twice in the db

tbid=19139461,19139635 were not accepted in the client even though the same
incident was recorded twice in the db.

use a 56k dialup over sera.
adt: need info.  Shiva, is this still a problem?  If so, are you getting no data
from win 98 users?  Are you getting significantly less talkback data versus
downloads as compared to milestones before this problem was reported?  Thanks.
Whiteboard: [need info]
Talkback data sending problem independent of the Platform. This problems is
occuring due to connection issues. We have actively solved many scenarios in
sending data. We are investigating few more connection type issues. 
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]
I am still having trouble with talkback.  Mozilla rarely crashes for me since I
tend to use major releases.  But most or every time it does crash I have
trouble.  The last time it happened is described <a
href='http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c28'>here</a> and <a
href='http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c29'>here</a>.

Well, Mozilla crashed yesterday, so I again have a talkback incident that I
can't submit.  I click on "send queued incidents" and then watch my 'bytes sent'
go up by 107000 each occasion, taking 30-60 seconds before popping up an error
message "The agent is unable to connect to the server.  Please check your proxy
settings or try again later."

I have a dial-up account with Freeserve, a major European ISP.  I am not
knowledgable about proxies (so it would be nice if the <a
href='http://www.mozilla.org/quality/qfa.html'>talkback documentation</a> didn't
assume otherwise), but I believe Freeserve offers an optional web cache
(www-cache.freeserve.com) while also allowing 'direct' Internet access without
any interference by proxies.  So I think these settings should work for me: no
HTTP proxy, no SOCKS proxy, yes ignore automatic proxy configuration settings

... but I have also tried some other permutations of proxy settings without
greater success.  I'm on Windows 2000 with Mozilla 1.4 (i.e. 20030624).


It might well be unrelated, but it appears that I can shut off my Internet
connection by trying too hard to submit an incident.  I connected to Freeserve
and started trying to submit this incident.  The first four attempts each
resulted in the sending of 107000 bytes.  The fifth attempt was only about
40000.  After this, webpages would not load (e.g. "bugzilla.mozilla.org could
not be found.  Please check the name and try again" or "The operation timed out
when attempting to contact www.bbc.co.uk").  Then a couple of minutes later the
connection closed by itself.  (On that occasion my IP address was
217.135.133.118 in case anyone has access to server logs.)

When the same thing happened last night it only took three attempts before I was
cut off.  The phenomenon reminds me of some occasions when I have tried to send
large email attachments via Freeserve and got cut off.  (At the time I
speculated it might be an anti-spam measure.)

I'm willing to try things at this end to help diagnose the problem.  Suggestions?
There are 3 or so bug reports that look like they match mine.

I picked this one because it has the most recent activity via comments.

...

When letting TalkBack do its thing after restarting Mozilla after
one of its infrequent crashes, I get:

---------------------------
Netscape Quality Feedback Agent
---------------------------
The Agent is unable to connect to the server.
Please check your Proxy Server settings or try again later.
---------------------------
OK
---------------------------

This happens after my modem's send and receive LEDs blink back and
forth for about a minute. So Talkback has obviously connected with
someone/something.

I diddle with all possible option setting in TalkBack, same thing.

I try turning off my firewall (ZoneAlarm), same thing.

I do a clean boot, start only TalkBack, same thing.

I try several times over a day or two, same thing.



I'm running Windows 2000 SP4, Mozilla 1.4, dial up 56k modem.

The same thing happened when I was using Win 2k SP3 and Mozilla 1.1.

The same thing happened when I was using Windows 98se and Netscape 4.7x.

(This never-ending TalkBack story also spanned multiple motherboards,
processors, and a more than one external modem.)

(do you detect a pattern?)



In the past I just turned off TalkBack after it was caught in a never-ending
loop of failed connections. (It got turned back on again with each upgrade of
Netscape/Mozilla -- then the cycle repeated. I kept thinking "they" would surely
hear about and fix this problem by the next release.)

Now I decide to make a bug report and it looks like this has been reported
many times from different environments over a long period of time.

I may not be reporting anything new, but it is important to note:
o this is a real problem
o it happens on many machines
o it spans several versions of Mozilla/Netscape
o it's not getting fixed

I'm not mad, but I do believe it leaves a very bad taste in people's
mouths to have a crash that can't get reported (remember they don't 
have any idea that it might be getting reported, they just see what is
on the screen.)



I will be glad to help engineers get a better handle on this, but I 
don't have any idea what more to tell them at this time.
WRITE TO ME and I'll send whatever/do whatever will help you.

Michael Carr
(In reply to comment #33)

I'm running into the exact same problem as Michael Carr (comment #33).  I've
*never* been able to send a TalkBack crash report.

I *always* get the "The Agent is unable to connect to the server. Please check
your Proxy Server settings or try again later." error.

I've tried everything Michael has tried.

Windows XP
Mozilla 1.8a (currently, but has occured on me since 1.2 and Win98)
Dialup
No proxy server
Earthlink ISP

Almost my entire time of using Mozilla, I've just ignored Talkback and disabled
it because of this problem.  I figured it was something that just doesn't work
and they just haven't taken out yet.  Now with the new push for all platforms to
have this "feature", I figured I'd actually spend more than a couple of hours
trying to get this to work.

Kevin Nehls



I've timed my talkback submissions while watching a packet trace, and it looks
like talkback starts a 30-second timer when it starts sending its submission. 
If  after 30 seconds, it hasn't received a response from the server, it aborts
the upload and pops up the generic "proxy error" dialog, even if it's still
sending the report!!   My trace shows it takes about 35 seconds to upload the
105k compressed report (consistent with a 24k modem rate).  Talkback was either
never tested with modem users, or mozilla is sending *huge* tracebacks compared
to Netscape 4.  Is there any way to raise the timeout from 30 seconds to 1
minute or more (maybe hexediting talkback.exe)? 

I need to test a theory of mine to see if any of your incidents are being
submitted even though you see the error message from Talkback.  Anyone that has
been having problems sending Talkback incidents, please try this:

1. Crash.
2. Fill out Talkback incident form, making sure to provide a complete email
address (or a unique comment that can easily be queried for).
3. Send.
4. Most likely observe the "unable to connect" error message.
5. Post the email address or unique comment you provided for the crash incident
in this bug.

Once I have a few, I will try to look up your incidents to see if they even get
to the Talkback database.  My testing in the past has shown that incidents are
often being submitted ok, but the user is not getting an update from teh server
telling them that the incident went through...instead, they are seeing this
connection error (making it appear that nothing was sent).
Just verifying... There have been a couple of reports in bug 210251 since the
last post here.

I am still seeing the problem, having just installed Firefox 1.0PR.  And as
documented in http://bugzilla.mozilla.org/attachment.cgi?id=154095&action=view,
each time the agent tries, CPU usage goes to 100%.

There should be an entry from 10:15 p.m. EDT beginning with "Upon loading page,".

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Dell Dimension 4100 (933 MHz), WinXP Pro SP1, modem connection, no proxy.
(In reply to comment #34)

I've upgraded to broadband and no longer have this problem.  I was able to
successfully send a crash/error report from Thunderbird without problems.

Kevin
In reply to comment #35, I took some readings while watching the agent send. 
This is the usual timeline:
   00:00 Agent starts automatically.  CPU pegs 100%.
   00:30 Dialog box closes.  CPU idle.  Data transmission continues.
   00:75 Data transmission ceases after sending about 220KB, receiving ~9K.
My throughput is about 50.6K.
Broadband is *not* an option.

<rant>
Does anyone care about this bug?  Nearly four years have passed since Bug 60968
was opened 2000-11-22, and the logs from that one, this one, Bug 167536 and Bug
210251 are full of observations, suggestions, and requests for workarounds or
alternative solutions for auto-reporting bugs.  
Comment #33 in this bug, posted a year ago, and
http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c48 from 18 months ago, are
cogent summaries of the situation and requests for action.
Please, either fix it, or stop shipping it with Mozilla Firefox 1.0 Preview
Release, which has now surpassed 1,000,000 downloads.
</rant>

I am tempted to label this Critical, but I will leave that to someone with more
authority.
Just another confirmation:

Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10

- Win98 SE (I think there's a pattern here)
- 56k dialup
- No proxies (as far as I know of. Not sure what my ISP is doing behind the
curtains)
- Never succesfully submitted a talkback from this machine (often tried).
(In reply to comment #36)
> I need to test a theory of mine to see if any of your incidents are being
> submitted even though you see the error message from Talkback.  

Today I saw talkback connecting, seemed to be successful, but I got an error
message.  As the fastfind server wasn´t busy, there was only one file waiting, I
just looked for the file number of that file, and then the preceding one, and
found my report.
I tried to resend it, but seems the server doesn´t accept duplicate reports, so
 I got same errormessage again. I already had successfully transmitted two
reports, and got that bug on the third one.


Anyone that has
> been having problems sending Talkback incidents, please try this:
> 
> 1. Crash.
> 2. Fill out Talkback incident form, making sure to provide a complete email
> address (or a unique comment that can easily be queried for).

I don´t recommend the email address, as you can´t search for this.
You only can search for text in the comment field, or the URL field,
besides searching for Talkback ID or Stack Signature.

See http://talkback-public.mozilla.org/talkback/fastfind.jsp

> 3. Send.
> 4. Most likely observe the "unable to connect" error message.
> 5. Post the email address or unique comment you provided for the crash incident
> in this bug.
> 
> Once I have a few, I will try to look up your incidents to see if they even get
> to the Talkback database.  
On Nov 1, Firefox informed me of an update to Talkback, so I installed it per
the directions, closed FF and restarted.  I then recreated my favorite
crash-inducing bug (bug # still unknown to me), whereupon Talkback initiated.  I
dutifully filled out the form and watched as Talkback began its usual sequence
of Peg-The-CPU then Transmit-For-Another-Half-Minute-Or-So-With-CPU-Idle then
Give-Up-And-Wait-Five-Minutes then Repeat.  I let the thing retry all night, and
now, almost 24 hours later, it has yet to succeed on the client end.

At least I know that the report did make it.  It is ID=1665908.
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=1665908

So I guess I will consider this closed when
A) At a minimum, the client end sends a complete report successfully
B) And ideally NOT peg the CPU for 30 seconds while doing that.  If that must be
a separate bug, that's OK.

Talkback software: Build date 2004-10-01@10:15AM; File version 2.2.0.0
(2.2.unofficial).

Mozilla Software: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1

Machine: WinXP SP2, 933 MHz Pentium 3, 384 MB RAM.
Blocks: 238292
Just another gentle reminder that this bug is really well over four years old,
and is now being seen by potentially millions of new Firefox and Thunderbird
users.  It is being tracked by both Bug 210251 and Bug 189702.  I cannot discern
any significant difference between these two, and between either one and the
original Bug 60968 (as well as many dups).  Hence I am cross-posting this update
in both.  (Continuing work on Talkback itself is tracked in Bug 238292.)

Once, after a crash independently on Fx and Tbird, I witnessed both instances of
Talkback trying unsuccessfully to complete.  While sends usually get through
(check via http://talkback-public.mozilla.org/talkback/fastfind.jsp), my PC is
at 100% CPU for ~ 75 seconds every few minutes.  This is absolutely unacceptable
to the average user.

Because of this, and for reasons I reiterated fully seven months ago
(https://bugzilla.mozilla.org/show_bug.cgi?id=189702#c39), I am going to try to
mark both Bug 210251 and Bug 189702 as Critical, if I can, and if I cannot, I
hereby request that someone with that authority to please do so ... or give a
cogent reason why not.  

If there is anything we end-users can do to help, please let us know.

WinXP Pro SP2, 933MHz Intel P3, dialup.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 
Firefox/1.0.3, TBird 1.0 (2004120606), Talkback 2.2
Just another confirmation from the latest version of Mozilla

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511

- Win98 SE
- 56k dialup
- I'm don't have a proxy. I've tried 2 different dial-up ISPes
  in case something my normal one does was blocking talkback)
- I'm not using a firewall

The sending status referes to talkback.mozilla.org. However if
I use netstat, it shows mothra.mozilla.org - netstat also shows
multiple connections/connection attempts.
Here's some information about my connection as reported by
http://www.broadband-help.com/cm_diagnose.asp

     Network
IP                 84.71.70.29  [WHOIS]
Host Name          Host name not found (0)

     Proxy
Proxied HTTP? 	   Yes
Proxy IP 	   195.92.67.74  [WHOIS]
Proxy Name(Raw)    1.1 webcacheH10 (NetCache NetApp/5.5R3D3)
Proxy Name(R-DNS)  webcacheH10a.cache.pol.co.uk

I am using the ISP "Freeserve" at the moment and although I do
not have a proxy configured on my computer, it appears
that "Freeserve" are re-directing my connections through one.

p.s. With "Freeserve" as the ISP. The failure mode is slightly
different. I tend to only get one line shown by netstat. The
talkback "sending status" pop-up's status starts with "connecting",
changes to "sending", then changes to "receiving". These changes
take under a second; the status then remains as "receiving" with
very little/no data appearing to be exchanged for approx 30 secs
before the error message "The Agent is unable to connect to the server.
Please check your Proxy Server settings or try again later."
is displayed. Netstat reports the connection is in the
"Established" state whilst the talkback "sending status" pop-up
is reporting "receiving". It changes to "Fin wait 2" when the
 error is displayed.

i.e This failure mode appears to match that initially reported
in another bug I've now found on talkback sending
https://bugzilla.mozilla.org/show_bug.cgi?id=265815

This is different from the failure experianced in comment
#35 in this bug. Are there multiple different ways that
Talkback fails?
Here's some information about my connection as reported by
http://www.broadband-help.com/cm_diagnose.asp
When I'm using my other dial-up ISP

     Network
IP                80.47.220.50  [WHOIS]
Host Name         dial-80-47-220-50.th.lond.access.as9105.com

     Proxy
Proxied HTTP? 	  No
Proxy IP 	  n/a  
Proxy Name(Raw) 	
Proxy Name(R-DNS) An invalid IP Address was passed. Resolution cannot be performed.
We have experienced an outage yesterday for few hours due to Talkback dependency
systems. Talkback Server is working. If you still have problems in sending the
incident please re-open the bug. 
  
  In general, you should be able to send incidents within few minutes of
occurance. Sometimes due to volume and other dependency issues it might take
longer time to send the incident.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.