1609668 - Crash during download via ServiceWorker

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Martin Vobruba]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Steps to reproduce:

Go to https://stat-info.cz/firefox-sw-readablestream.html and click Download button.

Actual results:

In background the page navigates to URL handled by ServiceWorker. SW responds with ReadableStream which is fetching data chunk by chunk (16MB) and download of 50GB file is initiated.

After downloading of 12-16GB tab crashes on my Mac. I have no problem to complete the download on Linux/Windows.

Unfortunately no crash report is generated but here are crash reports from another site which uses this technique for downloading:
https://crash-stats.mozilla.org/report/index/f023d407-4b56-4f59-8b12-5401b0200115
https://crash-stats.mozilla.org/report/index/abad85cc-6872-4bb5-87ad-ca10d0200115

Expected results:

The download should be completed without any crash.

Comment 1

[Martin Vobruba]

Alternative steps to reproduce this issue:

1. Open https://mab.to/oOr1opalDOu0N
2. Right click on folder "01_music ~ 2020-01-17" and click "Download as a ZIP archive"
3. Select location where to save the ~ 1.38GB file
4. If download is successful (no crash) click "Close" button in the left bottom corner and repeat from 2)

For me the tab crashed 4 times of 10 download attempts. Here are the crash reports:
https://crash-stats.mozilla.org/report/index/ca0f9218-f071-446c-9845-cd5500200117
https://crash-stats.mozilla.org/report/index/42086aa3-754c-400d-bb32-4d7d50200117
https://crash-stats.mozilla.org/report/index/5bc2db56-1f36-42e8-9b6c-76c380200117
https://crash-stats.mozilla.org/report/index/41ad6545-993f-4ff4-b48f-784940200117

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I tried reproducing the crash on my end but I'm able to download both files provided. I tried on Firefox Nightly 74.0a1 (2020-01-28) (64-bit) on macOS 10.14.

Indeed it's downloading chunk by chunk (16MB) for a download of 50GB file. It took several hours but it finally finished downloading successfully. FF didn't crash but I'm unable to open file or extract what's inside.

When trying the alternative steps within https://mab.to/oOr1opalDOu0N link provided, I managed to download the file without inconveniences as well.

I'm going to set a component so that the devs can take a look at the crash reports provided.

Does this issue occur with a fresh profile? You can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?

Best,
Clara

Comment 3

[Martin Vobruba]

I use a fresh profile on the current stable Firefox 72.0.2 to reproduce this issue.

As you recommended I tried the Nightly 74.0a1 several times (hundreds of GB downloaded) and it didn't crash for me either.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:gsvelto, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Gabriele Svelto [:gsvelto]]

Martin, can you confirm that this issue is not happening for you anymore as per comment 3? I've looked at the crashes in comment 0 and in comment 1 but they point to at least two different causes, one of which (illegal instruction executed) is really odd.

Comment 6

[Martin Vobruba]

I tried the current stable Firefox 73.0 and it crashed. See report here https://crash-stats.mozilla.org/report/index/51cc0b4b-8340-410f-85df-ed5710200213 . I will try beta and nightly versions later.

Comment 7

[Gabriele Svelto [:gsvelto]]

Thanks Martin, the cause for that crash report is even different compared to the previous ones. I suspect there might be a problem with your machine and since it only shows up when downloading very large files it might be faulty memory. Could you run a diagnostic on your Mac's memory? You can use memtest86 (which requires booting from an external USB stick) or macOS memory diagnostic tool (see here on how to launch it, under "Check Your Memory Using Apple Diagnostics" paragraph). memtest86 is preferable as it gives very detailed results but I never ran it on a Mac before so I don't know if it works there.

Comment 8

[Gabriele Svelto [:gsvelto]]

P4 since we couldn't confirm this yet.

Comment 9

[Martin Vobruba]

Since 81 this test is causing crashes even in Windows.

https://crash-stats.mozilla.org/report/index/2ef3d66f-0605-49bd-95d4-68cf90201002
https://crash-stats.mozilla.org/report/index/8d59ed91-d168-4db1-8f09-871b40201002
https://crash-stats.mozilla.org/report/index/28361a46-4fa7-49cf-92e0-ad9ac0201002

I ran the memtest86 and there were no issues with my memory.

Comment 10

[Gabriele Svelto [:gsvelto]]

Thanks, this is definitely actionable. I'll confirm the bug and attach the crash signature.

Comment 11

[Gabriele Svelto [:gsvelto]]

We're statically allocating a 32 KiB buffer on the stack and this seems to be causing stack overflows at least on Windows, but I suppose the issue affects all platforms.

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

bp-8d59ed91-d168-4db1-8f09-871b40201002 shows that there's some recursion making the problem worse: 7 activations of DoRead on the stack, including the one that overflowed. I looked at a disassembly and there don't seem to be any other functions involved in that recursion that have large frame sizes, so it should be enough to move that one allocation to the heap.

Comment 13

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1609668 - Move 32k buffer in IPCStreamSource::DoRead to the heap to avoid stack overflow.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/19e5e9a8e377
Move 32k buffer in IPCStreamSource::DoRead to the heap to avoid stack overflow. r=asuth

Comment 15

[Martin Vobruba]

I will test the change using nightly build. Is there any chance that this change will be backported to the current stable/beta version?

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/19e5e9a8e377

Comment 17

[Camelia Badau [:cbadau], Desktop Test Engineering]

Martin, could you please verify that the bug is fixed on Firefox 83 Beta 2 (https://archive.mozilla.org/pub/firefox/candidates/83.0b2-candidates/build1/)?

Comment 18

[Martin Vobruba]

I have done many tests using nightly or the latest beta and I can confirm that the bug is fixed. Is there any chance that this change will be backported to the current stable version?

Comment 19

[Camelia Badau [:cbadau], Desktop Test Engineering]

Thank you, Martin!
I will set the "firefox83" flag to verified.