[tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri May 12 15:40:11 UTC 2017
#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-------------------------------------------------+-------------------------
Reporter: gk | Owner: gk
Type: defect | Status:
| needs_review
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-usability, tbb-7.0-must-alpha, | Actual Points:
ff52-esr, TorBrowserTeam201705R, |
GeorgKoppen201705 |
Parent ID: | Points:
Reviewer: | Sponsor:
| Sponsor4
-------------------------------------------------+-------------------------
Changes (by gk):
* cc: arthuredelstein (added)
* keywords:
tbb-usability, tbb-7.0-must-alpha, ff52-esr, TorBrowserTeam201705,
GeorgKoppen201705
=>
tbb-usability, tbb-7.0-must-alpha, ff52-esr, TorBrowserTeam201705R,
GeorgKoppen201705
* status: needs_information => needs_review
Comment:
Okay, I am not fully done here as I seem to still have some details
missing (I need more detailed logs at that point) but so far the patch in
the attachment fixes things for me and looks good according to my logs I
took for the debugging purposes. I have a branch `bug_21886_v3`
(https://gitweb.torproject.org/user/gk/tor-
browser.git/commit/?h=bug_21886_v3&id=96a9fe10689345b0410b6ee25134de4e27c7c883)
for review.
The problematic NoScript part is:
{{{
if (IOUtil.isMediaDocOrFrame(req, contentType)) {
IOUtil.suspendChannel(req);
Thread.delay(() => IOUtil.resumeParentChannel(req), 100);
}
isMediaDocOrFrame(channel, contentType) {
try {
let cpType = channel.loadInfo.externalContentPolicyType;
if (cpType === 7 || (cpType === 6 &&
/^(?:video|audio|application)\//i.test(contentType === undefined
? channel.contentType : contentType))) {
try {
return !/^attachment\b/i.test(req.getResponseHeader("Content-
disposition"));
} catch(e) {
}
return true;
}
} catch (e) {
}
return false;
},
}}}
I don't really understand what `hread.delay(() =>
IOUtil.resumeParentChannel(req), 100);` but I suspect that the problems we
are seeing are caused by it.
What happens deeper down in the stack is the request being closed after
about 32768 bytes are handled because calling `onDataAvailable` is
resulting in an error that gets back to `OnStateStop`
(`NS_ERROR_UNEXPECTED`):
{{{
[Main Thread]: D/nsStreamPump nsInputStreamPump::OnInputStreamReady
[this=7f4591466180]
[Main Thread]: D/nsStreamPump OnStateTransfer [this=7f4591466180]
[Main Thread]: D/nsStreamPump Available returned [stream=89904d00 rv=0
avail=32768]
[Main Thread]: D/nsStreamPump calling OnDataAvailable [offset=0
count=32768(32768)]
[Main Thread]: D/nsHttp nsHttpChannel::OnDataAvailable [this=7f459a4da000
request=7f4591466180 offset=0 count=32768]
[Main Thread]: D/nsHttp sending progress and status notification
[this=7f459a4da000 status=804b0006 progress=32768/60562619]
[Main Thread]: D/nsStreamPump OnStateStop [this=7f4591466180
status=8000ffff]
[Main Thread]: D/nsHttp nsHttpChannel::OnStopRequest [this=7f459a4da000
request=7f4591466180 status=8000ffff]
}}}
I'd like to keep this ticket open until we understand in detail what is
going wrong but I think having the patch in the alpha can't hurt.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21886#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list