66393 - CPU 100% Hog on lots of sites

Status: VERIFIED DUPLICATE of bug 62388

(Core :: Networking, defect)

Description

[pla]

OS/2 version simply likes to eat CPU at any time.. I have constant CPU hogs on
lots of pages when I am using Mozilla at home.. Mike this bug was in Netscape
4.6 and is now in Mozilla, it simply likes to use CPU 100% :( To all other OS/2
users: Please decsribe if you have this thing too, because I do not want this
extremely bad bug to be left out just because all around have PIII :)

Comment 1

[Blake Ross]

*** Bug 66394 has been marked as a duplicate of this bug. ***

Comment 2

[Jure Repinc (JLP)]

Happens to me quite often (on TB 900). This has to be a dup of some other bug.
Reporter try to find a page where this happens always (or often). This would
help programmers to find the problem more easily.
Mozilla 2001012220 on Windows 2000 SP1 on PC.

Comment 3

[Dmitry Kubov]

Looks like it hangs if many connections opened but not connected or no data
tranferred yet. Happens on slow sites or links if many images not loaded.

Probably it gets stuck inside connections query...

Comment 4

[Keyser Sose]

Marking NEW as per comments.

Comment 5

[Dmitry Kubov]

Attachment: workaround fix

Comment 6

[Dmitry Kubov]

Try this workaround. Probably it not a good place for it, but it helps me.

Comment 7

[Mike Kaply [:mkaply]]

OK, I have some interesting debug info for this, not sure what it means. I did 
this testing on Windows, NOT OS/2.

I am using www.dpreview.com as my test.

I added code in nsSocketTransportService.cpp in the while loop inside of ::Run 
that keeps track of how many times we go through this loop (note this is a very 
tight loop)

What I found was that without the PR_Sleep, we went through the while loop 316 
times.

With the PR_Sleep we went through the loop 112 times.

On OS/2 during this time, the system was more responsive.

I have no idea if this data is completely invalid, but it is interesting.

Comment 8

[Darin Fisher]

The socket transport misbehaves when we have overlapped i/o.  This is being
worked on.  The PR_Sleep hack(s) are terrible and will go away when this is
finally resolved.

Comment 9

[neeti]

Adding dependency to meta bug.

Comment 10

[neeti]

looks a dup of 62388

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

Comment 11

[Tom Everingham]

verified dup