(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #142690 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=142690 Imported into Bugzilla on 01/04/99 16:10) Surf for a few pages, and the mac will freeze up in Delay(). What appears is happening is NSPR is waiting for data (which never arrives), so it goes into an infinite loop until something arrives, scheduling the main thread, sleeping, waking up, and rescheduling. This starves out the UI so the mac appears frozen.

Changing TFV to 5.0 SF1 in.

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

Accepted the bug. Bug 124235 was marked as duplicate of this bug. Added sdagley, gagan, and freier to the Cc list. I am studying the NSPR mac source code now. Is there any area that you think is the suspect? I suspect that PR_Poll may fail to report socket connection close as a readable event, so we don't know the download is done. I also discovered that NSPR's implementation of nonblocking socket I/O on the Mac is incorrect. If we always call PR_Poll first and only call I/O functions when the fd is readable or writable, then this is probably not a problem. Gagan, can you confirm that Netlib always calls PR_Poll before calling read/recv/write/send on sockets? I am not familiar with our user-level thread scheduling code and with Mac, so please be patient. I am doing my best to get up to speed.

Bug #124235 is a test stopper and a duplicate of this bug, so I guess this bug is a test stopper too. Assigned QA to glynn (same as in bug #124235).

I am adding Lou to the list. He did the NSPR20 upgrade and might know about this. Lou?

jar and I have decided that a fix for the Mac NSPR2 problem is no longer a requirement for ending the stability freeze so I'm moving the target fix version of this bug to 5.0. But Wan-Teh, Gordon, and Joe should continue with fixing this bug as their top priority.

Taking bug for Wan-Teh

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

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

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

This bug is slowing down our ability to do Mac testing greatly. What's the status on a fix?

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

gordon...whats the eta for some headway on this one? thanks!

Adding URL info.

I just played with Jan 25 Mac build and it looks better. What do you think elig?

The flaw in the Mac NSPR socket implementation is still there. I've been out sick for the past week, but this is my number one priority now.

Thanks, Gordon. <Purely anecodotally, Viewer doesn't seem to be crashingly nearly as often as a result of this particular problem on the more recent builds, believe it or not.>

Inserting Milestone info.

Setting all current Open Critical and Major to M3

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Gordon status on this puppy?

elig, can you try this with the latest Apprunner Mac build please. Win32 Mar13 build loads this URL ok.

Resolved as FIXED. Gordon checked in the stuff, so ... :-)

Whoo Hoo! Will check Monday morning :-) Changed to make myself, glynn as qa contact.

As far as I can tell this puppy appears fixed. March 15 builds. Marking verified, will reopen if necessary.

I got this just this morning on the tinderbox page (lockup in _Delay during networking). I don't think it was waiting for DNS lookup (which is still synchronous). Reopening bug. I really am terribly sorry, gordon.

Well ... crap. Grodon, is Mike on something or is it really back?

Resolved bug as FIXED. Since Pink or glynn can't reporduce the failure ...

Reverified until a reproducible example of new failure can be found.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.