Closed Bug 981323 Opened 10 years ago Closed 4 years ago

crash (low memory) while unpacking gigapixel images

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
28 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: lpauzner, Unassigned)

Details

(Keywords: perf)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

visit specially crafted page found in the wild:

<html>
<img src="http://upload.wikimedia.org/wikipedia/commons/7/71/South_America_and_Antarctica_at_night_by_VIIRS.jpg" height="1px">
<img src="http://upload.wikimedia.org/wikipedia/commons/8/87/Western_North_America_at_night_by_VIIRS.jpg" height="1px">
<img src="http://www.eso.org/public/archives/images/large/mmb-area-dawn-pano.jpg" height="1px">
<img src="http://farm8.staticflickr.com/7008/6438753145_814325b212_o.jpg" height="1px">
<img src="http://farm9.staticflickr.com/8058/8230410013_658ef96150_o.jpg" height="1px">
<img src="http://www2.iap.fr/users/pichon/MN-128-stars-colour.jpg" height="1px">
<img src="http://www.jazzlad.com/uploads/9/2/0/0/9200326/pd_downtown_dallas_from_www.jazzlad.com.jpg" height="1px">
<img src="http://celestialmusingsblog.files.wordpress.com/2012/06/moxxor_large-prints11.jpg" height="1px">
<img src="http://viz.olihb.com/wikilinks.jpg" height="1px">
<img src="http://laritaengelbrecht.yolasite.com/resources/Garden%20of%20Earthly%20Delights%20Large%20Panel%20SMALLER3.jpg" height="1px">
<img src="http://denr.sd.gov/des/mm/documents /Plate3.7-1VegetationMap10112.jpg" height="1px">
</html>


Actual results:

Firefox process bloated to 2Gb and crash with Low Memory message

Firefox 27.0.1 /Windows7x64  (perhaps other versions affected)


Expected results:

No crash.
Expect process memory some how related to the downloaded file size or display resolution.
You said there was a low-memory message? Did the crash produce a Firefox crash report?

This is unlikely to be a security issue that needs to remain hidden, but we should check your crash report ID before opening it up.
Flags: needinfo?(lpauzner)
It's definitely not a security issue, but people may publish pages with such images here and there to crash visitor' browsers. Up to you.
Flags: needinfo?(lpauzner)
Group: core-security
Loenid, Please post your crash report ID into this bug report.
Please find the IDs by opening a tab with address of  about:crashes
Severity: normal → critical
Flags: needinfo?(lpauzner)
Keywords: crash, stackwanted
Report ID 	Date Submitted
bp-d9cccd9d-0067-479f-9ac1-adebe2140319	19/03/2014	18:06

Steps to reproduce: save html in question to a local file, open file with Firefox 28.0
Flags: needinfo?(lpauzner)
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleForSize(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&) ]
Version: 27 Branch → 28 Branch
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleForSize(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&) ] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleForSize(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&) ] [@ OOM | large | mozalloc_abort(char const* const) | moz…
Crash Signature: mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleForSize(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&) ] → mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleForSize(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&) ] [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | mozilla::gfx::ImageHalfScaler::ScaleFo…
Leonid, have you seen this crashing recently?
Flags: needinfo?(lpauzner)
Whiteboard: [closeme 2016-07-15]
Well, Firefox 47 /Windows7x64 do not crash with the html in question.

While loading the page: memory bloated from 600M to 2G, a dozen of seconds at 100% CPU but everything responsive, finally memory 800M with no CPU usage. After deleting the tab: 100%CPU for a couple of seconds for GC, and memory shrink to 600M.

So it is "OK". A way too complex with (height="1px") but not critical.
We should probably try to figure out why we use so much memory and compare with
other UAs if they handle it better.
Severity: critical → normal
Component: General → ImageLib
Keywords: crash, stackwanted → perf
Whiteboard: [closeme 2016-07-15]
(clearing n-i? since Leonid already responded)
Flags: needinfo?(lpauzner)
All of the images are quite large: 22844x7087, 17801x4151, 16231x7884, 16384x16384, 32370x6646, 13500x13500, 13500x13500, 32370x6646, 12000x19200. While we are downscaling-during-decode appropriately, we still need a fair bit of memory to perform the decompression of the JPEGs. The main thread never blocks as it is the decoding thread pool consuming most of the CPU cycles. Note that the problem may be exacerbated by zooming in, triggering redecodes for a slightly larger size, and zooming in again while those decodes are in progress. Some rate limiting of how many (large) images we are willing to decode at once may be reasonable.

(The crash is still reproducible if I limit the memory the process can use.)
I was tald libjpeg can downscale images on the fly (by an integer factor), it should be a few lines to implement a call...
(In reply to Leonid from comment #10)
> I was tald libjpeg can downscale images on the fly (by an integer factor),
> it should be a few lines to implement a call...

I wrote a patch to take advantage of scaling for large images, however the memory savings is minimal. One of the images causes most of the allocations because it is a progressive image and thus always requires 3x full image sized buffers (not downscaled). This results in an extra ~732MB use for http://farm9.staticflickr.com/8058/8230410013_658ef96150_o.jpg. There are no knobs to tweak this as far as I can tell, because it is all based on parameters read in jpeg_reader_header, and nothing we supply.

Setup for the allocation happens here on the jpeg_read_header path:
https://dxr.mozilla.org/mozilla-central/rev/b7f7ae14590aced450bb0b0469dfb38edd2c0ace/media/libjpeg/jdinput.c#103
https://dxr.mozilla.org/mozilla-central/rev/b7f7ae14590aced450bb0b0469dfb38edd2c0ace/media/libjpeg/jdcoefct.c#659

Actual allocation follows from here on the jpeg_start_decompress path:
https://dxr.mozilla.org/mozilla-central/rev/b7f7ae14590aced450bb0b0469dfb38edd2c0ace/media/libjpeg/jdmaster.c#560

Closing because no crashes reported for 12 weeks.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.