Closed Bug 189672 Opened 22 years ago Closed 21 years ago

100% CPU, exhaust system resource, freeze mozilla, while displaying page

Categories

(Core :: Networking: HTTP, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.3beta

People

(Reporter: llo8or4sf, Assigned: darin.moz)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030118
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030118

Visit the page at http://www.geocities.com/squatter.geo/ or under the 
directories.
After some seconds, thorbber animation stops.
System resource is extremely reduced. If don't anything (exit mozilla, 
push ESC key, click Stop toolbar button or go another page), goes 0%.
Therefore freeze mozilla.


Reproducible: Always

Steps to Reproduce:
1. Visit the page. http://www.geocities.com/squatter.geo/
2. Wait for a while (about a minute).

Actual Results:  
Freeze Mozilla.
Resouce meter alarms few remain resouce.
Sometimes OS freeze also.


Expected Results:  
No freeze.

OS: Win98
2003-01-18-04-trunk (Build ID: 2003011804)
This worked for me on Windows XP, but to be more complete, what kind of
processor and how much memory do you have?
CPU: Celeron 466MHz (FSB 66MHz)
Memory: 196MB (128MB+64MB, PC100 SDRAM DIMM)

Usual system resouce percentage:
 just after Windows startup: about 70 percent
 just after Mozilla startup: 65-67 percent
There's something strange going on with this page.
While I can interact with the page just fine, the CPU usage goes to 100%, and
the throbber pretty much stops animating.    This happens even with Javascript
disabled.

Win2k 2003011808
Works fine on Linux/Solaris with cvs 20030115. Maybe a Windose specific bug ?
Saw a similar bug with yesterday's build (20030118) on some pages, but I don't
see it with today's build (2003011908), so possibly it's been fixed.
I still see this problem on 2003-01-19-08-trunk build.
I can see same problem on http://enigmail.mozdev.org/ .

per comment #3, I confirmed 100% CPU usage. I'll add summary it.
Summary: exhaust system resource, freeze mozilla, while this page displaying → 100% CPU, exhaust system resource, freeze mozilla, while displaying page
Also seeing this on http://enigmail.mozdev.org/ using build 2003012315 on WinXP
Home Edition.
i'm seeing the problem on http://enigmail.mozdev.org/ as well (pipelining
disabled, modem connection).  mozilla responds to the STOP button fortunately.

trunk 2003012308 win2k.

i'm going to guess that this is a regression from bug 176919.  taking.
Assignee: asa → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
Flags: blocking1.3b?
Keywords: regression
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
possibly a duplicate of bug 189843.  b/c with the patch for bug 189843 in my
tree i'm unable to repro the problem.  w/o it the problem happens 100% of the
time using the enigmail URL.
hmm.. now i'm not so certain about my last comment.  it is difficult to
reproduce the bug using a debug build.  using an optimized build w/ HTTP logging
enabled, i was able to determine that the problem is with a GIF being loaded...
the OnDataAvailable event delivered to imagelib is apparently being ignored.
Status: NEW → ASSIGNED
Looks like something we need to get fixed for 1.3
Flags: blocking1.3b? → blocking1.3b+
Attached patch v1 patchSplinter Review
ok, this patch adds some code to necko to detect and prevent the loop. 
however, detecting and patching around the problem is not the real answer to
this bug.  this patch also includes a bug that bz noticed in
nsSocketTransport::OpenOutputStream where we incorrectly flag the socket
_input_ stream as open instead of the socket _output_ stream.  funny that doing
so wouldn't hork the entire world, and maybe just maybe it might explain this
bug (or at least it probably explains some of the other bug 176919
regressions).
Attachment #112576 - Flags: superreview?(bzbarsky)
Attachment #112576 - Flags: review?(dougt)
...this patch also includes a bug _fix_ that bz noticed...
Comment on attachment 112576 [details] [diff] [review]
v1 patch

Looks good.  ;)
Attachment #112576 - Flags: superreview?(bzbarsky) → superreview+
Attachment #112576 - Flags: review?(dougt) → review+
Comment on attachment 112576 [details] [diff] [review]
v1 patch

Adding approval1.3b+.  I'm interested to see if the first of the changes in
nsSocketTransport2.cpp helps any of the crashes being reported in talkback.
Attachment #112576 - Flags: approval1.3b+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 189718 has been marked as a duplicate of this bug. ***
*** Bug 190508 has been marked as a duplicate of this bug. ***
*** Bug 190672 has been marked as a duplicate of this bug. ***
Setting All/All per comment 18.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 190659 has been marked as a duplicate of this bug. ***
This has propably caused bug 190946.
*** Bug 190158 has been marked as a duplicate of this bug. ***
FWIW, 'system resources' are only an issue on windows 9X, 3.X OSes. NT-based
OSes are limited only by availible memory, while 9x, 3.x have a fixed 'resource
area' that can be filled up if too many fonts, custom graphics, comboboxes,
widgets are in use.
no new reports for a while now and this WFM; verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.