1425208 - slow network download for merged Blob from FileSystem sliced one

Status: RESOLVED INVALID

(Core :: DOM: File, defect, P5)

Description

[Kaiido]

Attachment: down_bug.html

Following bug1424183, when trying to download a generated Blob from slices of a FileSystem's File, the downloading is like it comes from a slow network, and eventually crashes the browser.

On one of my computers, after clicking on "download" button in the attachment, the download speed is around 20kb/s, on an other computer, it just crashes the tab.

The slowness can also be seen when trying to play a merged video blob in a video element, somehow, the video element takes a long time to load it.

And to add to the weirdness, this doesn't happens with Blobs loaded through network (e.g fetch#blob()). In this case, there is absolutely no problem.

Comment 1

[Andrea Marchesini [:baku]]

> On one of my computers, after clicking on "download" button in the
> attachment, the download speed is around 20kb/s, on an other computer, it
> just crashes the tab.

I'm not able to reproduce it. But I have questions:

1. if you see a crash, can you submit a crash report?
2. about the slowness part: which OS are you using? Are you able to see if it changes using another OS? I ask this because on linux this issue seems unreproducible. I'm currently using a video of 16mb.

Comment 2

[Kaiido]

Both computers run osX 10.12, the one with slow download is a macBookPro, and the one with the Tab crash is an iMac.

The crash report from the macbook is here https://crash-stats.mozilla.com/report/index/a359249d-7162-4de0-bff2-738480171214

I don't have access to the iMac currently, nor to other OSes.


Note: since today's update, the download speed raised up to 2MBps on the macbook (only one tested), which is better, but still not normal since the same page ran on current stable 57.0.1 just don't show any download progress for the same 20MB file.

Running a mozregression against this new change revealed that bug1424183 did the improvement...
(pushlog range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1343829c156774a621b2164be5462eed31475a79&tochange=dfeab081202ff7718fa14cfdd1a6882058e816d3)

...But I am pretty confident I already had these patches yesterday since I was able to confirm the bug-fix.

Is there anything I can do to get more info on what happens on my machine?

Comment 3

[Andrea Marchesini [:baku]]

> Is there anything I can do to get more info on what happens on my machine?

Thanks for your help.

About the crash, it seems that you are reproducing an pre-existing issue related to "nsSocketTransportService::Poll". Let's NI somebody working on necko to see if they can help here.

About the speed, yes, bug 1424183 improved how nsMultiplexInputStream works, but we are still slow because your test makes firefox to do a lot of I/O. Definitely a lot more than a normal file download: for each sliced part, we must open a file descriptor, do a seek operation to reach the starting point, then finally, read data. I don't think there is much more to improve here, but I'll think about it more.

mayhemer, any idea about the crash? It seems it doesn't happen often and it has showed up since 57.

Comment 4

[Kaiido]

Ah because when we do "new Blob(blobParts)" the returned Blob still contains the slices internally, and is not a new merged one made of a single slice? I didn't know that.

Also, when I said "still not normal since the same page ran on current stable 57.0.1 just don't show any download progress for the same 20MB file", I meant that when I run the same code (attachment 8936770 [details]) from the current stable branch, I don't see the download progress at all.  
So I think there is still a regression from 57 to now.

Comment 5

[Honza Bambas (:mayhemer)]

Dragana, what do you think about this crash?  https://crash-stats.mozilla.com/report/index/a359249d-7162-4de0-bff2-738480171214

It doesn't look like something known...  


Kaiido, how many times was you able to reproduce that crash?

Comment 6

[Kaiido]

(In reply to Honza Bambas (:mayhemer) from comment #5)

> Kaiido, how many times was you able to reproduce that crash?

I waited until full browser crash only once, but my computer's fans started to spin really fast numerous times when running attachment8936770 [details] with cancelling the download; before patch from bug1424183 has been applied.
Closing the tab eventually avoided the crash.

I may try to downgrade to a rev prior to bug1424183 fix to reproduce if it helps, but I don't know if I'll get time to do it today.

Comment 7

[Kaiido]

Attachment: from_external_no_bug.html

This attachment has the same code as the first attachment, but doesn't reproduce the slow download bug. 
The only difference between both codes is that the first one used an user input file, while this one uses a Network fetched Blob.

I think this goes against the assumption that slowness is caused by I/O induced by sliced Blob (but I may be wrong).

Anyway, as stated in comment4, this doesn't happen in current stable 57 and would be a regression.

Comment 8

[Dragana Damjanovic [:dragana]]

Our crash reports are deleted due to bug 1427111.

Can you reproduce the crash again?

Comment 9

[Andrea Marchesini [:baku]]

> I think this goes against the assumption that slowness is caused by I/O
> induced by sliced Blob (but I may be wrong).

Yes, I suspect it's just I/O. I don't think there is more to do here.

Comment 10

[Jens Stutte [:jstutte]]

No more reproduction submitted.