289275 - After about an hour of using Chatzilla it slows downand is hard to close. At this time my system is still running fine.

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Matt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

While using Chatzilla for a few hours it starts to get very slow and becomes
unusable. If I minimize it the rest of my system is running fine. I then have
trouble closing it down.

Reproducible: Always

Steps to Reproduce:
1.open chatzilla
2.use for a few hours
3.

Actual Results:  
While using Chatzilla for a few hours it starts to get very slow and becomes
unusable. If I minimize it the rest of my system is running fine. I then have
trouble closing it down.

Expected Results:  
Not slowed down.

Comment 1

[Matt]

My system specs:
Processor
Model : AMD Athlon(TM) XP 3200+
Speed : 2.20GHz
Model Number : 3200 (estimated)
Performance Rating : PR3190 (estimated)
Type : Standard
L2 On-board Cache : 512kB ECC Synchronous Write-Back (16-way, 64 byte line size)

Mainboard
Bus(es) : AGP PCI IMB USB i2c/SMBus
MP Support : No
MP APIC : Yes
System BIOS : Award Software, Inc. ASUS A7V600-X ACPI BIOS Revision 1002
System : System Manufacturer System Name
Mainboard : ASUSTeK Computer INC. A7V600-X
Total Memory : 1024MB DDR-SDRAM

Chipset 1
Model : ASUSTeK Computer Inc VT8377 Apollo KT400/A/600 CPU to PCI Bridge
Front Side Bus Speed : 2x 200MHz (400MHz data rate)
Total Memory : 1024MB DDR-SDRAM
Memory Bus Speed : 2x 200MHz (400MHz data rate)

Video System
Monitor/Panel : Dell M770
Adapter : SAPPHIRE RADEON 9600 ATLANTIS
Adapter : SAPPHIRE RADEON 9600 ATLANTIS - Secondary

Physical Storage Devices
Removable Drive : Floppy disk drive
Hard Disk : WDC WD2000JB-00FUA0 (186.3GB)
CD-ROM/DVD : _NEC DVD_RW ND-2500A (CD 40X Rd, 32X Wr) (DVD 5X Rd, 4X Wr)

Logical Storage Devices
1.44MB 3.5" (A:) : N/A
Hard Disk (C:) : 128.0GB (53.4GB, 42% Free) (NTFS)
Expansion (D:) : 543MB (0MB, 0% Free) (CDFS)
New volume (E:) : 58.3GB (58.3GB, 100% Free) (NTFS)

Peripherals
Serial/Parallel Port(s) : 1 COM / 1 LPT
USB Controller/Hub : VIA Rev 5 or later USB Universal Host Controller
USB Controller/Hub : VIA Rev 5 or later USB Universal Host Controller
USB Controller/Hub : VIA Rev 5 or later USB Universal Host Controller
USB Controller/Hub : VIA Rev 5 or later USB Universal Host Controller
USB Controller/Hub : VIA USB 2.0 Enhanced Host Controller
USB Controller/Hub : USB Root Hub
USB Controller/Hub : USB Root Hub
USB Controller/Hub : USB Root Hub
USB Controller/Hub : USB Root Hub
USB Controller/Hub : USB Root Hub
Keyboard : Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
Mouse : Microsoft USB IntelliMouse Optical
Human Interface : HID-compliant game controller
Human Interface : Microsoft USB IntelliMouse Optical
Human Interface : USB Human Interface Device

MultiMedia Device(s)
Device : Standard Game Port
Device : SoundMAX Integrated Digital Audio

Printers and Faxes
Model : HP DeskJet 840C on pc2
Model : HP DeskJet 840C

Power Management
AC Line Status : On-Line

Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional (Win32 x86/IA32)
5.01.2600 (Service Pack 2)

Network Services
Adapter : VIA Rhine II Fast Ethernet Adapter

Comment 2

[:Gijs (he/him)]

Confirming bug based on the report of this in #chatzilla. While we could just
set an upper limit to the number of events processed each step (which is what I
did for the reporter to solve the problem), this would not be preferred, as the
eventsPerStep variable should NEVER be Infinity in the first place. If anyone
has a clue as to what may have caused this, that would be most helpful.

Comment 3

[James Ross]

(In reply to comment #2)
> Confirming bug based on the report of this in #chatzilla. While we could just
> set an upper limit to the number of events processed each step (which is what I
> did for the reporter to solve the problem), this would not be preferred, as the
> eventsPerStep variable should NEVER be Infinity in the first place. If anyone
> has a clue as to what may have caused this, that would be most helpful.

Is that what happened? eventsPerStep was Infinity?

(not all of us were in #chatzilla ;) )

Comment 4

[:Gijs (he/him)]

Yes, that is what happened. I asked the reporter to eval the parameters used for
the event queue, because they are the things that tend to cause slowdowns.

Comment 5

[:Gijs (he/him)]

Attachment: Patch

Patch to check for the time difference to be bigger than 0 (having it be 0
causes the increment newValue to go to Infinity)

R? = Silver

Comment 6

[James Ross]

Comment on attachment 179847 [details] [diff] [review]
Patch

Not totally sure this will fix the bug, but it can't hurt.

r=[e-mail]

Comment 7

[Asa Dotzler [:asa]]

Comment on attachment 179847 [details] [diff] [review]
Patch

a=asa

Comment 8

[James Ross]

Checked in --> FIXED (hopefully). Reporter, if the behaviour still occurs with
the 2005-04-21 21:00 build from the site below, please re-open this bug.

Automated builds at http://twpol.dyndns.org/mozilla/chatzilla/nightly/ will
include this shortly.