Closed Bug 310739 Opened 19 years ago Closed 18 years ago

Resuming of file download hangs

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Version:
1.8.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sskroeder, Unassigned)

References

Details

(Keywords: regression) 

NB : this bug is in latest (2005-10-01) Firefox 1.5 beta  (Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.8b5) Gecko/20050930 Firefox/1.4)

During download of a file with the download manager, if one selects Pause - and
thereafter tries to resume the download - the download fails to resume -- it
seems as it's still paused
Flags: blocking1.8b5?
Ok ... after some checking up - this bug does not exist in the 1.5 beta 1
release (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5b1) - but is
apparently introduced in the subsequent nightlies...

please advise as how to proceed with this bug - is it relevant (some download
seems flawed) or not (one can't expect all nightlies to work flawlessly) ??

/Søren



Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051001
Firefox/1.4.1 ID:2005100105

I don't see a button Pauze in the Download Manager in Windows: only Cancel. When
I click Cancel the button changes into Retry, when I click Retry the download
starts all over again.
I've tested this downloading from an FTP repository and cannot reproduce with
the latest branch nightly. I can reproduce using HTTP.

Darin and Mike, this seems pretty bad. Can you guys look into it? 

Søren, can you help us pin down the day this broke by testing more nightly builds?

Tracy, can you help here too. 

Steps to reproduce. Download a file over HTTP (ex.
http://stage.mozilla.org/pub/mozilla.org/mozilla/interviews/mitchell-baker-interview-oscon-2005.mp3
) Press the "Pause" link under the download progress meter. Then press the
"Resume" link and note that the download fails to resume.
Flags: blocking1.8b5? → blocking1.8b5+
Keywords: qawanted
Tested with todays 10/03 Linux 1.4.1 Fx build.  Pause/Resume in the download
dialog work fine with the http link Asa provided.   Hmmmm, had left it in pause
while I began to file this report, returned and resumed it. Now it is stuck. 
Clicked Cleanup and it then proceeded.  But I can't reproduce that reliably.
Hi Asa (and others)

I've made a test of all Linux 1.8 nightlies since 2005-09-17 -- all previous
builds are unavailable...

I tested resuming of 
  A http download (based in US) [1]
  A http download (based in DK) [2]
  A ftp download  (based in US) [3]

In all cases i tested about 2-3 times - to see if i got false positives/negatives

Further more i used a clean profile - and cleared the cache before testing each
build...

Legend:
P  = Pass on all tests
F  = Fail on all tests
PF = Passed on some - failed on others

           | HTTP (US) | HTTP (DK) | FTP (US)
-----------+-----------+-----------+----------
2005-09-17 |     F     |     P     |    P
2005-09-18 |     P     |     P     |    P
2005-09-19 |     P     |     P     |    P
2005-09-20 |     P     |     P     |    F
2005-09-21 |     P     |     P     |    P
2005-09-22 |     P     |     P     |    P
2005-09-23 |     P     |     P     |    P 
2005-09-24 |     P     |     P     |    P
2005-09-25 |     P     |     P     |    P
2005-09-26 |     P     |     P     |    P
2005-09-27 |     F     |     PF    |    P
2005-09-28 |     P     |     P     |    PF
2005-09-29 |     PF    |     P     |    P
2005-09-30 |     PF    |     P     |    P
2005-10-01 |    ----   |   ----    |   ----- 
2005-10-02 |     PF    |     P     |    PF
2005-10-03 |     PF    |     P     |    P
-----------+-----------+-----------+---------

Since there is more PF/F's in US tests, i'm wondering if this has something to
do with how quickly the reply from the server is, when trying to resume...

I'm not familiar with the download code - but does it continue trying to resume
the download (a couple of times) if contacting a server times out on resuming? 

On a side note -- At first, i did some tests on my own profile - with Download
Statusbar extension... And after uninstalling it, the resumes passed on more
(not all) occasions -- that was when i decided to test using a clean profile -
and with cleared cache...

/Søren

  Sources
------------
[1]
http://stage.mozilla.org/pub/mozilla.org/mozilla/interviews/mitchell-baker-interview-oscon-2005.mp3
[2] http://www.lambda.dk/test (7mb tar.gz of latest da 1.8 nightly)
[3]
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-l10n/firefox-1.4.1.bg.linux-i686.tar.gz

http://archive.mozilla.org/ has older builds fwiw.
I can intermittently reproduce this on a stock 1.0.6 build/profile, and on
current trunk.  Its a bug, yes, but I think this is probably a dupe, and not a
blocker, IMO.
I can reproduce this consistently. If we cannot fix this, can we please remove
the feature, or at least the UI for it?
(In reply to comment #8)
> I can reproduce this consistently. If we cannot fix this, can we please remove
> the feature, or at least the UI for it?

Have you observed the problem with both HTTP and FTP?  I think removing the
feature would be overkill.  Sure, it happens to not function reliably across the
board, but for some people (myself included) it seems to just work.
This works flawlessly for me on FTP and fails consistently on HTTP. It doesn't
make sense for enabling it for one and not the other, though, I think.

We'll revisit for RC1
Flags: blocking1.8rc1+
Flags: blocking1.8b5-
Flags: blocking1.8b5+
I get a lot of assertions with my CVS build Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.9a1) Gecko/20051004 Firefox/1.6a1. When I try to resume a download
it is working sometimes and sometimes not. So I tried to shutdown the main
window and canceled there the download. At this moment following assertions are
shown within the console:

WARNING: requested removal of nonexistent window
, file
../../../../../../mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 999
--WEBSHELL 0x8469810 == 2
###!!! ASSERTION: Rejecting event posted to uninitialized sts:
'PR_GetCurrentThread() != gSocketThread', file
../../../../../mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 129
Break: at file
../../../../../mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 129
###!!! ASSERTION: unable to post continuation event: 'Error', file
../../../../mozilla/xpcom/io/nsStreamUtils.cpp, line 442
Break: at file ../../../../mozilla/xpcom/io/nsStreamUtils.cpp, line 442
###!!! ASSERTION: Rejecting event posted to uninitialized sts:
'PR_GetCurrentThread() != gSocketThread', file
../../../../../mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 129
Break: at file
../../../../../mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 129
###!!! ASSERTION: unable to post continuation event: 'Error', file
../../../../mozilla/xpcom/io/nsStreamUtils.cpp, line 442
Break: at file ../../../../mozilla/xpcom/io/nsStreamUtils.cpp, line 442
Keywords: regression
And what I forgot... these lines are the last ones before shutdown:

--WEBSHELL 0x847d548 == 1
nsPluginHostImpl::Observe "xpcom-shutdown"
--DOMWINDOW == 11
--DOMWINDOW == 10
--DOMWINDOW == 9
--DOMWINDOW == 8
WARNING: nsExceptionService ignoring thread destruction after shutdown, file
../../../../mozilla/xpcom/base/nsExceptionService.cpp, line 191
--DOMWINDOW == 7
--DOMWINDOW == 6
+++ JavaScript debugging hooks removed.
--DOMWINDOW == 5
--DOMWINDOW == 4
GC Cache:
        hits: 27966 1306  981  562  212  380  287   24  223  213
        hits: 32154, misses: 2875, hit percent: 91,792511%
JS engine warning: 29 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
###!!! ASSERTION: Main thread being held past XPCOM shutdown.: 'cnt == 0', file
../../../../mozilla/xpcom/threads/nsThread.cpp, line 478
Break: at file ../../../../mozilla/xpcom/threads/nsThread.cpp, line 478
nsStringStats
 => mAllocCount:          42499
 => mReallocCount:         3784
 => mFreeCount:           42074  --  LEAKED 425 !!!
 => mShareCount:          35397
 => mAdoptCount:           2939
 => mAdoptFreeCount:       2847  --  LEAKED 92 !!!

I tried to download some files from
ftp://ftp.informatik.uni-frankfurt.de/pub/Mirrors/ftp.debian.org/debian-cd/current/i386/iso-cd/

This server only allows four connections from a host. After playing around I
wasn't able download any file. A popup will say that only four connections are
allowed. It seems that the used http channel isn't freed anymore.
I see exactly what Asa sees in Comment 10 using today's build on the Mac when
trying to download from the Mozilla Mirror site - Mozilla/5.0 (Macintosh; U; PPC
Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051010 Firefox/1.4.1.  I went to our
Mozilla Mirrors site and tried testing back and forth between FTP and HTTP. I
have no trouble with FTP, but consistent trouble with HTTP. I did clear my cache
before testing and was using an existing profile.

When I went to do download.com and downloaded a movie trailer, I did not see the
issue.  Also tried downloading a few more files from various HTTP sites
including
(https://jsecom15b.sun.com/ECom/EComActionServlet/DownloadPage:~:com.sun.sunit.sdlc.content.DownloadPageInfo;jsessionid=7DD50E4C21BE469F99A5DBB5E3186C11;jsessionid=7DD50E4C21BE469F99A5DBB5E3186C11)
and did not see the issue with pausing and resuming.
Darin, do any of those asserts look related?
Flags: blocking1.8rc1+ → blocking1.8rc1-
*** Bug 315517 has been marked as a duplicate of this bug. ***
made a test today with Firefox 2.0 beta 2 - and pausing and resuming downloads over HTTP worked flawlessly ... 

Can i regard this bug as fixed  ?
Yeah, I will resolve this as WORKSFORME, but I have a hunch it might've been fixed by bug 342375.
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.