Note: There are a few cases of duplicates in user autocompletion which are being worked on.

ChatZilla appears connected but nothing sends (commands or messages) - 100% CPU usage

RESOLVED FIXED

Status

Other Applications
ChatZilla
--
critical
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: wsmwk, Assigned: Robert Ginda)

Tracking

({hang})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Caused by bugs listed in "depends on" below)

Attachments

(1 attachment, 1 obsolete attachment)

Chatzilla 0.9.67+ [SeaMonkey 1.1a/2005102013]

Channel appears to be operational - messages are received, and messages typed in input area are put in the displayed in the conversation log, and therefore appear to have been sent to the channel.   (open moznet channels were: seamonkey, chatzilla, developers, bugs)

But 
a) no one else in the channel sees my messages and 
b) no commands work (/join, /leave, /motd, /list, etc) - they are accepted without error and there is no response
c) private chat requests don't connect

My nickname=wsm. Possibly related events:
* different machine running IRC with similar nickname wsmwk crashed earlier in the day
* jsconsole entry, don't know if this occured at same time as my trouble started, or perhaps long before --  Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIControllers.removeController]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://navigator/content/navigator.js :: Shutdown :: line 808" data: no]  (similar to bug 2438893)

Comment 1

12 years ago
I wouldn't be surprised if this is just the Mozilla timers screwing up (which they've been doing rather too frequently of late). Check this:

  /eval this.primServ.sendQueue.length

On any connected server. If it's >100 you have got the timer problem, which we can't do anything about, and you really should restart Mozilla or Firefox to fix.

And PLEASE don't file bugs like this in the NEW state, it is definately UNCO for now.
(Reporter)

Comment 2

12 years ago
(In reply to comment #1)
> I wouldn't be surprised if this is just the Mozilla timers screwing up (which
> they've been doing rather too frequently of late). Check this:
> 
>   /eval this.primServ.sendQueue.length
> 
> On any connected server. If it's >100 you have got the timer problem, which we
> can't do anything about, and you really should restart Mozilla or Firefox to
> fix.

will be able to test this in the future I'm sure - as I've had this problem multiple times.  what should be "normal" or nominal value?
 

> And PLEASE don't file bugs like this in the NEW state, it is definately UNCO
> for now.

agree, realized my mistake as soon as I clicked commit.

Comment 3

12 years ago
For several weeks this happened to me in the OS/2 trunk, but the problem seems to have disappeared recently.

Comment 4

12 years ago
Void comment 3. It just did it again in 2005120512 OS/2 trunk.
(Reporter)

Comment 5

12 years ago
Bug 291386 is implicated
Depends on: 291386
Summary: channels appear to be connected but no commands work and messages are not visible to others - chatzilla stopped working → channels appear to be connected but no channel commands work [/nick, /motd, /list, etc] and your messages are not visible to others, but you see their messages - in effect chatzilla is hung. possible 100% cpu

Comment 6

12 years ago
Created attachment 205147 [details] [diff] [review]
[checked in] Catch bug 291386 in the act and explain to the user

This patch will alert the user when the queue reaches 1000 items (very unlikely normally), and then with an ERROR at 10,000 and every 1000 after that.
Attachment #205147 - Flags: review?(samuel)
(Reporter)

Comment 7

12 years ago
mod up to OS=ALL (known to happen on OS/2 and windows, no report yet of linux or mac)

keyword=hang (chatzilla is essentially hung)
Severity: major → critical
Keywords: hang
OS: Windows 2000 → All

Comment 8

12 years ago
Comment on attachment 205147 [details] [diff] [review]
[checked in] Catch bug 291386 in the act and explain to the user

Yes, please :)
Attachment #205147 - Flags: review+

Updated

12 years ago
Attachment #205147 - Flags: review?(samuel) → review+

Updated

12 years ago
Attachment #205147 - Attachment description: Catch bug 291386 in the act and explain to the user → [checked in] Catch bug 291386 in the act and explain to the user
Attachment #205147 - Attachment is obsolete: true

Updated

12 years ago
Depends on: 318419

Comment 9

12 years ago
*** Bug 320160 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
*** Bug 320160 has been marked as a duplicate of this bug. ***

Comment 11

12 years ago
*** Bug 320267 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Summary: channels appear to be connected but no channel commands work [/nick, /motd, /list, etc] and your messages are not visible to others, but you see their messages - in effect chatzilla is hung. possible 100% cpu → ChatZilla appears connected but nothing sends (commands or messages) - 100% CPU usage

Updated

12 years ago
Whiteboard: Caused by bugs listed in "depends on" below

Comment 12

12 years ago
Created attachment 207327 [details] [diff] [review]
workaround

With this workaround I haven't seen the Excess Flood problems anymore.
*ErrorCounters are there just for debugging. (And I can see that the
counters have been increased quite much during the weekend while chatzilla was running.)

Updated

12 years ago
No longer depends on: 291386

Comment 13

12 years ago
I think this should be fixed with trunk ChatZilla on trunk Firefox/SeaMonkey/XULRunner now?

Per:
https://bugzilla.mozilla.org/show_bug.cgi?id=318419#c23 (which I am assuming is about bug 307527, but I'm not sure about this).

There is also work done on bug 318419, but no checkins there yet.

Can someone confirm whether this problem has gone away?
(Reporter)

Comment 14

12 years ago
I have not upgraded - waiting for these guys to settle down with their patch ideas.  But I can test it over the next few days.  

Does rebooting the PC help induce the wrap problem?

Comment 15

12 years ago
(In reply to comment #14)
> Does rebooting the PC help induce the wrap problem?

No, it resets it, in fact. The problem occurs at multiples of the wrap point since the start of Windows.

Comment 16

12 years ago
Ok, since bug 318419 is fixed and a release made with it in (Firefox 1.5.0.1) I propose that this bug is FIXED.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.