Closed Bug 161525 Opened 22 years ago Closed 21 years ago

Hang during download

Categories

(Camino Graveyard :: Downloading, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sfraser_bugs, Assigned: bryner)

References

Details

(Keywords: hang)

Attachments

(1 file)

I'm seeing hangs now when doing FTP downloads, which I haven't seen before. I've
seen them on a dual CPU machine; haven't tried to repro on a single CPU machine.
They've been happening for the last couple of days.
Blocker. I can't download new builds.
Severity: normal → blocker
wtc, I'm guessing from the sampler report that this is some kind of pthread
deadlock, and it coincidentally happened when I checked in the patch from bug
153525 for building on Jaguar.  Any ideas?
bryner: I have no idea.  Thread_0's stack in the sampler
report looks incorrect.
->bryner as the current best guess
Assignee: saari → bryner
Blocks: 147975
Adjusting summary, as I just reproduced this on a single-CPU machine.

wtc: It's unclear to me exactly what the implications are of #defining
PT_NOSIGTIMEDWAIT.  It certainly causes different code to be hit in ptthread.c.
 Could this cause some kind of thrashing when switching threads, or anything
like that?
Summary: Hang during download on dual CPU machine → Hang during download
I was also able to reproduce this problem with my original patch from bug
153525, where there should be no change at all for NSPR on OS 10.1.  This leads
me to think that the problem existed before these changes landed.  I'll do some
more testing on older builds.
FWIW, WorksForMe using Chimera/2002080605.
is this still happening for folx?
Component: General → Downloading
Keywords: hang
QA Contact: winnie → petersen
WFM too. I'm using a Power Mac Dual 800 mhz and haven't seen this problem in
latest builds.
I haven't seen this for ages. WFM?
Severity: blocker → normal
Hum...I can't seem to reproduce this on some FTP sites I found linked off
FreeBSD.org.  I'm not having issues...
Severity: normal → critical
WFM by consensus
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
No longer blocks: 147975
This has come back to bite us in the ass.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 184934 has been marked as a duplicate of this bug. ***
It's either deadlocking, or iterating in nsPipe::GetReadSegment:

http://lxr.mozilla.org/mozilla1.0/source/xpcom/io/nsPipe2.cpp#243

It doesn't look like deadlock with another thread; the socket transport thread
is blocked in poll().
I can consistently repro by trying to download the Google API's:

http://www.google.com/apis/download.html

Don't know if this is redirected to an FTP download or not.

Using 1.2.1 on Win2000 -- should this be a separate bug for non-MacOSX issues?
This bug is specific to Chimera on Mac OS X. Please file a separate bug for your
case.
I can't reproduce this bug with 2003080802 build.

I'm capable of downloading builds of Camino from the ftp server
(ftp://ftp.mozilla.org/pub/camino/nightly/latest/, Comment #2?) and downloading
the Google api's using the url given in Comment #17 works just fine to. 
WFM also, using the indicated test cases
WFM also, using the indicated test cases: Build ID: 2003081202
I'm going to resolve WFM (again & with a little hesistation)... 

closest thing to this behavior i've seen... think late spring... downloading
nighlies regularly failed but that was due to issues with dead ftp servers
somewhere in the cluster/round robin/whatever and had different symptoms entirely
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: