822407 - data:URL for huge image set in img.src can freeze Firefox for several seconds (possibly forever)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

I am currently attempting to extract a minimal usecase.

Comment 1

[David Teller [:Yoric] - still alive but not very active]

Use case: http://yoric.github.com/Bugzilla-822407
Caution: this sometimes causes crashes (at least with Aurora 19.02, MacOS X).

Comment 2

[David Teller [:Yoric] - still alive but not very active]

I actually meant "freeze", rather than "crash", but the OS informs me that the app is unresponsive.

Also, the example uses a very large image, but I have encountered it with much smaller images, when developing a small e-book reader web app.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Is this a regression?

Comment 4

[Boris Zbarsky [:bzbarsky]]

So... This image is a 31MB JPEG.  It's 9648x8168 pixels, looks like.  That's going to allocate about 315MB of RAM just decoding the image...  There are also going to be a few hundred megs of copies of the image floating around due to all the conversions back and forth in that testcase (from raw data to base64 and then back).

Have you had this problem only with images, or with other data: URIs too?

Comment 5

[David Teller [:Yoric] - still alive but not very active]

I have had this problem with 2-3Mb images.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Need a profile/stack here.

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Attachment: Process sample

Attaching a sample obtained through MacOS X's application monitor, after the browser had been at 100% CPU for a few minutes.

Comment 8

[David Teller [:Yoric] - still alive but not very active]

So, the browser eventually becomes responsive again, but after several minutes.
Profile: http://people.mozilla.com/~bgirard/cleopatra/#report=48fafe1be2c899ce423d8875e72d02fdb63bb83c

Comment 9

[David Teller [:Yoric] - still alive but not very active]

I have attempted to reproduce this with a fresh profile and with an older FF, with the following results:

- the "hang forever" effect seems to only apply with my current profile and Aurora, so it may be related to an add-on – it lasts 23 minutes (!) at full CPU, unresponsive app, with the attached profile;

- the "hang for several seconds" effects seems reproducible on FF17, without any specific profile – according to my measures we have a reproducible stutter between frames that can last anything between 2000ms and 8000ms on Aurora according to my in-script measures. During at least part of this stutter, the browser is not responsive.

Profile for this second measure, on FF17: http://people.mozilla.com/~bgirard/cleopatra/#report=2a844d0924087fe376bceada35f1f841b285e6e5

I have used requestAnimationFrame to measure the duration of the stutter.

Comment 10

[Boris Zbarsky [:bzbarsky]]

David, thanks.

The sample in attachment 693265 [details] shows something very interesting:

1)  All the actual CPU is being spent on regexp matching in a worker.
2)  The main thread is blocked on the worker because of memory reporting (presumably for
    telemetry; this is supported by the profile in comment 8, which shows all the
    main-thread time spent under TelemetryPing.js).

That's just broken.  I filed bug 822713.  Presumably the worker regexp matching is indeed caused by some addon, and again presumably it's doing some sort of regexp with lots of backtracking on the data: URI.  It might be interesting for bug 822713 to figure out what the addon is and what it's doing.

The profile in comment 9 shows for the big red area all the time being spent under xhr.onload/reader.onload in bug.js:54.  There's a bunch of PL_Base64Decode, memchr, memmove, unknown symbols.  David, do you think you can repeat that with a nightly and a clean profile?  That might give us better profiling info...

Comment 11

[David Teller [:Yoric] - still alive but not very active]

|profiler analyze| seems to take forever on the latest Nightly. I will try again tomorrow.

Comment 12

[Maurice Courtois]

Hi all,

I am experiencing a similar issue with: 

window.open('data:image/png;base64,' + data) 

on FF 21 OSX 10.8.3 taking. The image is only 438kb and would freeze FF for up to 2 minutes.

Comment 13

[David Teller [:Yoric] - still alive but not very active]

Maurice, out of curiosity, do you have Ghostery installed?
I have been able to trace some issues to Ghostery, but I'm not sure it's the onlyl culprit.

Comment 14

[Maurice Courtois]

No issue when firebug is disabled.

Comment 15

[Maurice Courtois]

It definitively seems to be cause by firebug in my case. 

(In reply to David Rajchenbach Teller [:Yoric] from comment #13)
> Maurice, out of curiosity, do you have Ghostery installed?
> I have been able to trace some issues to Ghostery, but I'm not sure it's the
> onlyl culprit.

Comment 16

[Juriy "kangax" Zaytsev]

I'm experiencing horrible freezes too, while working with data:url images. They're large, but not THAT large — 3000x3000px. "FirefoxNightly" seems to eat up to 5GB of disk space, tons of RAM, and makes entire OS unresponsive (it's crazy that OS X is even allowing process to get so greedy but that's besides the point).

Comment 17

[Boris Zbarsky [:bzbarsky]]

Juriy, are you using Firebug?

If not, it might be worth filing a new bug on your issue, with a testcase (that is, the specific data: URL involved).

Comment 18

[Juriy "kangax" Zaytsev]

Thanks, Boris. Created a new ticket — https://bugzilla.mozilla.org/show_bug.cgi?id=1095165 Not sure which component to mark it as, so used "HTML: Parser". Please change if necessary.