1418626 - An iteration of my site can make Firefox crash when using Blob features

Status: RESOLVED INCOMPLETE

(Core :: DOM: File, defect)

Description

[wanderingcoder]

Attachment: Archive.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0.1 Safari/604.3.5

Steps to reproduce:

- Load http://wanderingcoder.net/projects/JPS-dev/ffBugDemonstrator2/
- Load an unrelated page in another tab (mine was https://daringfireball.net/)
- uncompress attached "Archive.zip"
- set result file "base" as the "original file" in the loaded web page
- set result file "input.ips" as the "IPS format patch" in the loaded web page
- click button "apply patch"
- wait about five minutes



Actual results:

It varies. Once Firefox as a whole crashed, and once it remained stuck forever with the spinning pizza of death (preventing the use of the other tabs). The impact is pretty much the same.

(note: I have since improved my site code so as to avoid this issue, so this is not a problem for my site development, but the security issue remains)


Expected results:

Ideally, a download button for the result of the processing appearing. (this is what happens with Chrome)

Failing that, the tab going down more or less hard, but without taking down other tabs.

Comment 1

[Daniel Veditz [:dveditz]]

I could not reproduce this in Firefox 57 or 58 Beta, instead I get an immediate alert 

> "Could not apply patch file, are you sure it is an IPS file? (patch file does not begin by "PATCH")"

I checked and input.ips does start PATCHg"""""""""""""" ...

Comment 2

[wanderingcoder]

I don't understand, because I reproduce it just fine; I even tried redownloading the attachment and unzipping it in case it got corrupted on upload, and the resulting files do reproduce for me.

Make sure:
- you're on a Mac (it might matter)
- you unzip with archive utility, and that
- MD5 (base) = ca2be2d84fa0db25dd0a5b0c04390e93
- MD5 (input.ips) = 2a6a034c7cb7b9570857099711778abd
- base is at the top and input.ips at the bottom slot
- if you still can't repro at that point, try and vary the setup, because I'm out of ideas…

Comment 3

[Andrea Marchesini [:baku]]

Can you please submit a crash report? You can find the UUID in about:crashes. Thanks!

Comment 4

[wanderingcoder]

Oh, no problem, here is the ID: 9a60484b-3df7-4f75-9fb0-0656a0171128 (it has been uploaded as far as I can tell). You might notice the stack trace is slightly deep…

Comment 5

[Andrea Marchesini [:baku]]

Can you please check again using the tomorrow nightly? I did several changes in nsMultiplexInputStream and maybe they cover this issue as well. I cannot be more precise because I cannot reproduce it locally yet.
Thanks!

Comment 6

[wanderingcoder]

Sorry I couldn't try earlier, I just did with Nightly 59.0a1 (2017-12-03) (64 bits)…

And sorry, it still crashes. I couldn't locate the crash in about:crashes, but I have to assume it is the same.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

I tried this in a Linux ASAN nightly build - after a few minutes it said "base patched".    wanderingcoder, can you try again in an updated nightly?  (and get a crash report if possible if it does).  Thanks

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 57, so far, more investigation is stalled on getting a new crash report and STR.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

wanderingcoder: due to the reason we released 57.0.3, we've deleted all crash reports -- can you force a crash and log it here?  Thanks!

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Closing as incomplete given our inability to reproduce and lack of response from the original reporter. Reporter, feel free to reopen and provide an updated crash ID if you can still reproduce!