Closed
Bug 981323
Opened 11 years ago
Closed 4 years ago
crash (low memory) while unpacking gigapixel images
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
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.
|
||
Comment 1•11 years ago
|
||
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)
|
|
||
Updated•11 years ago
|
Group: core-security
|
||
Comment 3•11 years ago
|
||
Loenid, Please post your crash report ID into this bug report.
Please find the IDs by opening a tab with address of about:crashes
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)
|
||
Updated•11 years ago
|
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&) ]
|
||
Updated•11 years ago
|
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…
|
||
Updated•9 years ago
|
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…
|
|
||
Comment 5•9 years ago
|
||
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.
|
||
Comment 7•8 years ago
|
||
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
Whiteboard: [closeme 2016-07-15]
|
||
Comment 9•8 years ago
|
||
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.)
|
Reporter | |
Comment 10•8 years ago
|
||
I was tald libjpeg can downscale images on the fly (by an integer factor), it should be a few lines to implement a call...
|
|
||
Comment 11•8 years ago
|
||
(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
|
||
Comment 12•4 years ago
|
||
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.
Description
•