"Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in my browser tree

In Tor Browser 4.0-alpha-3, tonight I clicked Help -> About Tor Browser and then clicked to find updates, and it did, and it downloaded the thing, and then when I went back to the update download window it said "Update Failed. Download the latest version." where the second sentence is a link to https://www.torproject.org/download/download-easy.html

Mike told me I should report it, so here we are.

As a good bug reporter, I should also tell you that I was using the default obfs3 bridges at the time. (Mike says this shouldn't be relevant, but, here we are.)

added component::applications/tor browser owner::tbb-team priority::medium resolution::duplicate severity::normal status::closed type::defect labels

(32-bit Linux on Debian Wheezy)

Is that reproducible? If so, the log output (sanitized if needed) you get in your terminal, after flipping app.update.log in your about:config, might give us some clues.

*** AUS:SVC Downloader:onProgress - progress: 51970048/51998732
*** AUS:SVC Downloader:onProgress - progress: 51986432/51998732
*** AUS:SVC Downloader:onProgress - progress: 51998732/51998732
*** AUS:SVC Downloader:onStopRequest - original URI spec: https://www.torproject.org/dist/torbrowser/4.0/tor-browser-linux32-4.0_en-US.mar, final URI spec: https://www.torproject.org/dist/torbrowser/4.0/tor-browser-linux32-4.0_en-US.mar, status: 0
*** AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 10, retryTimeout: 2000
*** AUS:SVC Downloader:_verifyDownload called
*** AUS:SVC Downloader:_verifyDownload downloaded size == expected size.
*** AUS:SVC Downloader:_verifyDownload hashes match.
*** AUS:SVC Downloader:onStopRequest - setting state to: pending
*** AUS:SVC canStageUpdatesSession - testing write access /home/arma/tor-browser_en-US/Browser/update.test
*** AUS:SVC canStageUpdatesSession - testing write access /home/arma/tor-browser_en-US/update.test
*** AUS:SVC canStageUpdatesSession - able to stage updates
*** AUS:SVC canStageUpdatesSession - testing write access /home/arma/tor-browser_en-US/Browser/update.test
*** AUS:SVC canStageUpdatesSession - testing write access /home/arma/tor-browser_en-US/update.test
*** AUS:SVC canStageUpdatesSession - able to stage updates
*** AUS:SVC Downloader:onStopRequest - attempting to stage update: Tor Browser 4.0
*** AUS:SVC readStatusFile - status: failed: 6, path: /home/arma/tor-browser_en-US/Browser/updates/0/update.status
*** AUS:SVC handleFallbackToCompleteUpdate - install of complete or only one patch offered failed.
*** AUS:SVC UpdateManager:refreshUpdateStatus - Notifying observers that the update was staged. state: failed, status: failed: 6

In tor-browser_en-US/Browser/updates/last-update.log I find

Performing a background update
SOURCE DIRECTORY /home/arma/tor-browser_en-US/Browser/updates/0
DESTINATION DIRECTORY /home/arma/tor-browser_en-US/Browser/updated
ensure_copy_recursive: path doesn't exist: /home/arma/tor-browser_en-US/Browser/tord-log, rv: -1, err: 75
failed: 6
calling QuitProgressUI

and sure enough, I do have a tord-log file -- it comes from this line in my tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc:

Log debug file tord-log

Trac:
Summary: "Update failed" from 4.0-alpha-3 to "Update failed" from 4.0-alpha-3 when I have a log line in my torrc

Thanks for the detailed bug report. brade and I are out of the office for the next couple of days, so we won't be able to investigate and fix this right away.

So /home/arma/tor-browser_en-US/Browser/tord-log does exist? Is there any reason the updater would not be able to read it?

That file does exist, and it should be readable.

But a) it's 3 gigs, and b) it's open and being appended to by the Tor process. 'a' shouldn't matter, but I wonder if 'b' does.

Replying to arma:

That file does exist, and it should be readable.

But a) it's 3 gigs, and b) it's open and being appended to by the Tor process. 'a' shouldn't matter, but I wonder if 'b' does.

Actually, a) may be the problem. Here is the implementation of ensure_copy_recursive(): https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-31.2.0esr-4.x-1:/toolkit/mozapps/update/updater/updater.cpp#l736

The "err: 75" that was logged indicates errno 75 after a call to lstat(), which is EOVERFLOW. On your 32-bit system, I think lstat() will fail like this on any files larger than 2GB. I wonder if Mozilla has an open bug for this problem....

Yes indeed, the large file was the problem. Remove it and everything works fine.

No idea if Mozilla has an open bug for this issue. :)

Trac:
Summary: "Update failed" from 4.0-alpha-3 when I have a log line in my torrc to "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in my browser tree

FWIW: this is https://bugzilla.mozilla.org/show_bug.cgi?id=1108985.

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Maybe we should close this ticket in favor of #18186 (moved) ?

Trac:
Reviewer: N/A to N/A
Sponsor: N/A to N/A

Sounds good, done.

Trac:
Resolution: N/A to duplicate
Status: new to closed

Actually, this bug might have been resolved by not doing the staged updating anymore (see rstrong's https://bugzilla.mozilla.org/show_bug.cgi?id=1108985#c6).

Replying to gk:

Actually, this bug might have been resolved by not doing the staged updating anymore (see rstrong's https://bugzilla.mozilla.org/show_bug.cgi?id=1108985#c6).

Yes, it should be. The updater no longer tries to make a copy of user files during the update process.

closed

mentioned in issue #18186 (moved)

moved to tpo/applications/tor-browser#13433 (closed)