Closed Bug 820379 Opened 12 years ago Closed 12 years ago

crash in mozilla::dom::CanvasRenderingContext2D::GetImageDataArray

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Version:
19 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21
Tracking Flags:
Tracking Status
firefox18 --- unaffected
firefox19 + wontfix
firefox20 + verified
firefox21 --- verified

People

(Reporter: scoobidiver, Assigned: roc)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file)

fix handling of OOM
3.29 KB, patch
mattwoodrow
: review+
lsblakk
: approval-mozilla-aurora+
lsblakk
: approval-mozilla-beta+
Details | Diff | Splinter Review
It's #43 top browser crasher in 19.0a2. It first showed up in 19.0a1/20121015 and is discontinuous across builds. It's likely a regression from bug 806279. Signature mozilla::dom::CanvasRenderingContext2D::GetImageDataArray(JSContext*, int, int, unsigned int, unsigned int, JSObject**) More Reports Search UUID 8dd9f1f7-563c-41f5-90e9-ba4d82121211 Date Processed 2012-12-11 06:56:08 Uptime 152 Last Crash 1.9 days before submission Install Age 3.4 hours since version was first installed. Install Time 2012-12-11 03:34:29 Product Firefox Version 20.0a1 Build ID 20121210030747 Release Channel nightly OS Windows NT OS Version 5.1.2600 Service Pack 3 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 23 stepping 10 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x2e32, AdapterSubsysID: 301b17aa, AdapterDriverVersion: 6.14.10.5082 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x2e32 Total Virtual Memory 2147352576 Available Virtual Memory 1019871232 System Memory Use Percentage 81 Available Page File 1938190336 Available Physical Memory 390385664 Frame Module Signature Source 0 xul.dll mozilla::dom::CanvasRenderingContext2D::GetImageDataArray content/canvas/src/CanvasRenderingContext2D.cpp:3470 1 xul.dll mozilla::dom::CanvasRenderingContext2D::GetImageData content/canvas/src/CanvasRenderingContext2D.cpp:3392 2 xul.dll mozilla::dom::CanvasRenderingContext2DBinding::getImageData obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp:1757 3 xul.dll mozilla::dom::CanvasRenderingContext2DBinding::genericMethod obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp:3244 4 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:389 5 mozjs.dll js::Interpret js/src/jsinterp.cpp:2341 6 mozjs.dll js::RunScript js/src/jsinterp.cpp:346 7 mozjs.dll UncachedInlineCall js/src/methodjit/InvokeHelpers.cpp:370 8 mozjs.dll js::mjit::stubs::UncachedCallHelper js/src/methodjit/InvokeHelpers.cpp:458 9 mozjs.dll js::mjit::stubs::UncachedLoweredCall js/src/methodjit/InvokeHelpers.cpp:421 10 mozjs.dll js::mjit::stubs::CompileFunction js/src/methodjit/InvokeHelpers.cpp:247 11 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:1115 12 mozjs.dll js::Interpret js/src/jsinterp.cpp:2396 13 mozjs.dll js::RunScript js/src/jsinterp.cpp:346 14 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:404 15 mozjs.dll js::Invoke js/src/jsinterp.h:112 16 mozjs.dll js::CallOrConstructBoundFunction js/src/jsfun.cpp:1092 17 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:389 18 mozjs.dll js::Invoke js/src/jsinterp.h:112 19 mozjs.dll js::Invoke js/src/jsinterp.cpp:442 20 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:389 21 gkmedias.dll setContext parser/expat/lib/xmlparse.c:5628 More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Adom%3A%3ACanvasRenderingContext2D%3A%3AGetImageDataArray%28JSContext*%2C+int%2C+int%2C+unsigned+int%2C+unsigned+int%2C+JSObject**%29
Needs investigating what ImageData is doing with the CC. http://dxr.mozilla.org/mozilla-central/content/canvas/src/ImageData.cpp.html#l18 NS_IMPL_CYCLE_COLLECTING_ADDREF(ImageData) NS_IMPL_CYCLE_COLLECTING_RELEASE(ImageData) NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(ImageData) NS_INTERFACE_MAP_ENTRY(nsISupports) NS_INTERFACE_MAP_END NS_IMPL_CYCLE_COLLECTION_CLASS(ImageData) NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN(ImageData) NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mData) NS_IMPL_CYCLE_COLLECTION_TRACE_END NS_IMPL_CYCLE_COLLECTION_TRAVERSE_BEGIN(ImageData) NS_IMPL_CYCLE_COLLECTION_TRAVERSE_SCRIPT_OBJECTS NS_IMPL_CYCLE_COLLECTION_TRAVERSE_END NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN(ImageData) tmp->DropData(); NS_IMPL_CYCLE_COLLECTION_UNLINK_END
So the crash is in GetImageDataArray... I don't see what this has to do with ImageData, per se; there is no ImageData object at this point yet. The crashing line is this: 3470 uint8_t b = *src++; and it's a null-deref. That's the first use of "src" in cases when srcReadRect.IsEmpty(). In cases when srcReadRect is not empty, src is set to readback->GetData(), then read as above. Could readback->GetData() be returning null? As far as bug 806279, that landed a month before this bug first appeared, so I doubt it's the culprit here even if there _were_ any ImageData around in this code. Which there are not.
Component: DOM → Canvas: 2D
No longer blocks: 806279
It's #21 top browser crasher in 19.0b4 and #41 in 20.0a2. All users talk about PDF Viewer or what they though is the new look of Adobe Reader/Sumatra PDF plugin. Note: The PDF plugin enabled in the add-on manager, not used and without any warning for the change (PDF Viewer would have been blocklisted according to the third-party add-on policy) is disturbing for many users.
status-firefox18: --- → unaffected
status-firefox21: --- → affected
tracking-firefox19: --- → ?
Keywords: needURLs
Definitely triggered by PDF.js, top URLs: 5 http://www.valentinum.cz/files/ocenovani_starozitneho_porcelanu_2.pdf 4 https://www.esl.org/onlineserv/HB/StatementDisplayer.cgi 4 http://12tails.herorangers.com/comic/home.html 4 http://www.valentinum.cz/files/ocenovani_starozitneho_porcelanu_1.pdf 4 about:blank 4 http://www.cke.edu.pl/images/stories/pdf/biuletyn/tablice_fizyka.pdf 3 http://www.regione.piemonte.it/foreste/cms/media/files/pian_gest/dwd/nuova_legge/3204_14122012.PDF 3 http://www.keralacm.gov.in/images/stories/images/2012/calendar2013.pdf 3 https://blackboard.missouristate.edu/bbcswebdav/pid-1664656-dt-content-rid-7696377_1/courses/PLS101-SP13-21641/PLS101-SP13-21641_ImportedContent_20130114125406/Course%20Documents%20Required%20Readings%20Readings%20for%20Summary%20%231%20%281%2028%29%20Roc 3 https://easywebsoc.tdcanadatrust.com/eStatementPdf/TD_REBATE_REWARDS_VISA_CARD_1823_Jan_28-2013.pdf 3 http://www.astra-honda.com/app/webroot/upload/katalog/PC-New%20TIGER%20Revo.pdf 3 http://www.daikintech.co.uk/Data/Split-Sky-Air-Indoor/FDXS/2011/FDXS-E7VMB/FDXS-EAVMB_IM.pdf 3 http://husafridun.eplica.is/media/arsskyrslur/Tregluggar1.pdf 3 http://www.chicagomanualofstyle.org/facsimile/CMSfacsimile_rules.pdf 3 http://www.cke.edu.pl/images/stories/pdf/biuletyn/tablice_chemia.pdf 3 http://im.rediff.com/news/2013/feb/04criminal-law-ordinance-2013.pdf 3 http://www.valentinum.cz/files/ocenovani_starozitneho_porcelanu_3.pdf 3 http://www.dalekovod-tim.com/EasyEdit/UserFiles/pdf/istegnuti-materijali-i-ogradni-sustavi.pdf 3 http://innsyn2.e-kommune.no/innsyn_jolster/wfdocument.aspx?journalpostid=2013000505&dokid=37355&versjon=1&variant=A&ct=RA-PDF 3 http://www.aai.aero/aai_employees/pms_nonexecutive_7ag12.pdf
Keywords: needURLs
Anthony - can you take a stab at reproducing? roc - any initial ideas on what could be going wrong here?
Assignee: nobody → roc
Keywords: qawanted, steps-wanted
QA Contact: anthony.s.hughes
I managed to trigger this crash while scrolling on the following URL with Firefox 19.0b5 on Windows 8 64-bit: http://innsyn2.e-kommune.no/innsyn_jolster/wfdocument.aspx?journalpostid=2013000505&dokid=37355&versjon=1&variant=A&ct=RA-PDF Unfortunately I had all those URLs in comment 4 and was hitting them randomly so this might have just been a coincidence. At the very least, the crash is somewhat reproducible. I don't have more specific steps to reproduce yet, I'll try to narrow it down.
It seems to happen most frequently for me when I'm flipping through the pages on that document with the thumbnail pane visible and while it's trying to load the thumbnails. I also noticed that memory usage is at 3.3GB while working with this PDF (maybe OOM?)
I'm going to drop steps-wanted for the time being. It seems poking around randomly with the thumbnail pane loading for the document in comment 6 is the easiest way to trigger this. Though it seems to crash randomly, I can usually get it to crash within 5 minutes. Please let me know if there's something more I can provide.
Keywords: steps-wanted → reproducible
Sounds very much like we're hitting OOM constructing GetDataSurface and then crashing due to returning null from GetData. Since these are potentially very big allocations I think it makes sense to check them and throw a DOM exception if they fail.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #7) > It seems to happen most frequently for me when I'm flipping through the > pages on that document with the thumbnail pane visible and while it's trying > to load the thumbnails. I also noticed that memory usage is at 3.3GB while > working with this PDF (maybe OOM?) I think someone should file a bug against PDF.js about excessive memory usage, based on this.
Comment on attachment 711620 [details] [diff] [review] fix handling of OOM Review of attachment 711620 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. We have other callers of GetDataSurface that aren't checking if GetData() is valid though.
Attachment #711620 - Flags: review?(matt.woodrow) → review+
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #11) > I think someone should file a bug against PDF.js about excessive memory > usage, based on this. I filed bug 839548.
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/91a509f46a49 for failures in mochitest-1, mochitest-3 (mochitest-2 on Android), mochitest-4 (mochitest-6 on Android), mochitest-browser-chrome and mochitest-chrome. Oh, and mochitest-1 and mochitest-6 on b2g.
And jsreftest crashes on Windows.
See Also: → 839904
We're wontfixing for FF19 at this point, given how close we are to release. We don't expect this to block the feature, although it will be discussed during sign-off.
status-firefox19: affected → wontfix
This landed with incorrect bug number (8203709): https://hg.mozilla.org/mozilla-central/rev/0b32c50a1bec Please can you backout-reland (with DONTBUILD), to fix hg blame :-)
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox21: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
I really don't think that's worth it.
With the latest Nightly, I'm still seeing large memory spikes and hangs with the PDF mentioned in comment 6, but I'm not seeing the crash anymore. Please add the verifyme keyword if this lands on other branches.
status-firefox21: fixed → verified
Keywords: qawanted
It's #16 top browser crasher in 19.0 so I think it's worth an uplift to 20.0 Beta.
Keywords: topcrash
Comment on attachment 711620 [details] [diff] [review] fix handling of OOM [Approval Request Comment] Bug caused by (feature/regressing bug #): Unknown User impact if declined: Crashes on OOM Testing completed (on m-c, etc.): Landed and fix verified Risk to taking this patch (and alternatives if risky): Low risk patch, just adding an OOM check. String or UUID changes made by this patch: None.
Attachment #711620 - Flags: approval-mozilla-beta?
Attachment #711620 - Flags: approval-mozilla-aurora?
Comment on attachment 711620 [details] [diff] [review] fix handling of OOM Approving for uplift to branches, low risk and early in FF20 beta cycle so we can see how this helps the numbers.
Attachment #711620 - Flags: approval-mozilla-beta?
Attachment #711620 - Flags: approval-mozilla-beta+
Attachment #711620 - Flags: approval-mozilla-aurora?
Attachment #711620 - Flags: approval-mozilla-aurora+
It's already in Aurora.
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 I don't get any crashes with Firefox 20 beta 2 (buildID: 20130227063501) but still seeing large memory spikes when scrolling through the PDF from comment 6 and with others from comment 4.
status-firefox20: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: