crash in mozilla::gfx::DrawTargetD2D::CopySurface with PDF Viewer

VERIFIED FIXED in Firefox 19

Status

()

--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: scoobidiver, Assigned: milan)

Tracking

({crash, regression, steps-wanted})

19 Branch
mozilla21
x86
Windows 7
crash, regression, steps-wanted
Points:
---

Firefox Tracking Flags

(firefox19+ verified, firefox20+ verified)

Details

(crash signature)

(Reporter)

Description

6 years ago
It's #42 top browser crasher w/o hangs in 19.0a2.
It started spiking in 19.0a2/20121126 when Aurora was released.

Here are some comments:
"Tried zooming into the pdf using pdfjs addon --> Firefox crashed."
"I was visualising a PDF using the Mozilla extension for pdf.js (using the extension, not the built-in pdf.js function). The PDF was about AMD product overview regarding its AMD Turion II Neo processors."

Asking for tracking because of PDF Viewer.

Signature 	mozilla::gfx::DrawTargetD2D::CopySurface(mozilla::gfx::SourceSurface*, mozilla::gfx::IntRect const&, mozilla::gfx::IntPoint const&) More Reports Search
UUID	33d5dcb8-f47c-4b1e-810e-c6a0c2121206
Date Processed	2012-12-06 15:01:26
Uptime	20857
Last Crash	5.3 weeks before submission
Install Age	5.8 hours since version was first installed.
Install Time	2012-12-06 09:08:09
Product	Firefox
Version	19.0a2
Build ID	20121205042014
Release Channel	aurora
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 42 stepping 7
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
User Comments	pdf viewer crashed.
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0116, AdapterSubsysID: 17ca103c, AdapterDriverVersion: 8.15.10.2509
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x0116
Total Virtual Memory	4294836224
Available Virtual Memory	957005824
System Memory Use Percentage	95
Available Page File	499261440
Available Physical Memory	130965504

Frame 	Module 	Signature 	Source
0 	gkmedias.dll 	mozilla::gfx::DrawTargetD2D::CopySurface 	gfx/2d/DrawTargetD2D.cpp:721
1 	xul.dll 	mozilla::dom::CanvasRenderingContext2D::PutImageData_explicit 	content/canvas/src/CanvasRenderingContext2D.cpp:3737
2 	xul.dll 	mozilla::dom::CanvasRenderingContext2D::PutImageData_explicit 	content/canvas/src/CanvasRenderingContext2D.cpp:3743

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Agfx%3A%3ADrawTargetD2D%3A%3ACopySurface%28mozilla%3A%3Agfx%3A%3ASourceSurface*%2C+mozilla%3A%3Agfx%3A%3AIntRect+const%26%2C+mozilla%3A%3Agfx%3A%3AIntPoint+const%26%29

Comment 1

6 years ago
Although this is outside our typical top crash range, reading PDFs isn't common but is a critical user action. Including all the folks that will be able to take a look. KaiRo will provide URLs for QA to reproduce.
tracking-firefox19: ? → +
tracking-firefox20: --- → +
Keywords: qawanted, steps-wanted
QA Contact: anthony.s.hughes

Comment 2

6 years ago
Some URLs from this signature - I filtered out some URLs that didn't look like PDFs.

2 	http://ard.bmj.com/content/49/4/212.3.full.pdf
2 	http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:1984:126:0020:0026:EN:PDF
1 	http://www.youtube.com/watch?v=4n3deSPFXP0
1 	http://processing.org/learning/topics/animator.html
1 	http://www.online-stopwatch.com/spanish/full-screen-stopwatch.php
1 	https://www.dropbox.com/sh/bldejmun63ufylx/yXhfJ6YUdI/NovelEffects.pdf
1 	http://i20fever.com/univsel.pdf
1 	http://www.stanford.edu/dept/physics/publications/oldquals/Qual1999.pdf
1 	http://www.idautomation.com/scanners/SC7-USB-2D-Barcode-Scanner-Manual.pdf
1 	http://pra.aps.org/pdf/PRA/v46/i3/p1279_1
1 	https://www.dropbox.com/s/oic18redrc0uhaf/PL%20R2RFP%20Docs.pdf
1 	http://yarukizero.files.wordpress.com/2012/06/cah-grognards.pdf
1 	http://booksnow2.scholarsportal.info/ebooks/oca5/34/lecenacledejosep02scuoft/lecenacledejosep02scuoft.pdf
1 	http://server/SAIBAOnline/UploadDocument/Docs/22965/72872/72872-1.pdf
1 	http://resources2.kb.nl/010460000/pdf/DDD_010460335.pdf
1 	http://pegase.scd.inpl-nancy.fr/theses/2010_DOS_REIS_F.pdf
1 	http://pra.aps.org/pdf/PRA/v15/i1/p128_1
1 	http://studrada.fpm.kpi.ua/archive/Oxford%20English_4_IT.pdf
1 	https://www.dropbox.com/s/fsk6q1xuuddwf3u/Standar_Biaya_Umum_2012.pdf
1 	http://www.tax.gov.kh/files/6.pdf
1 	http://nickwritesmusic.com/public/brouwerpaper.pdf
1 	http://www.psc.gov.np/uploads/201212121355303033.pdf
1 	http://www.hartetechnologies.com/manuals/Unclassified/8080_Machine_Language_Programming_for_Beginner.PDF
1 	http://jpdb.nihs.go.jp/jp14e/14data/General_Test/Microbial_Limit_Test_for_Cr.pdf
1 	http://ia700304.us.archive.org/2/items/emhaemha/ifbqaa1.pdf
1 	http://www.roadsystems.com/pdf/skt/SKT-Install-Manual.pdf
1 	http://www.hyundai.com/in/en/wcm/groups/webcontent/@in/documents/webbasiccontent/317351.pdf
1 	http://www.ece.ucsb.edu/Faculty/Rabiner/ece259/Reprints/341_telecom%20applications.pdf
1 	http://www.scribd.com/doc/512787/Techniques-in-Immunology
1 	http://www.turner-white.com/pdf/brm_Rheu_V6P3.pdf
1 	http://www.ferrol.es/documentos/urbanismo/EI_Acceso-PEX_Fe/PDF%20Fase%20B/1-Memoria%20y%20Anejos/2-Anejos/Anejo%20N%C2%BA11%20Tuneles.pdf
1 	http://www.amd.com/us/Documents/48243_ASB2_Platform_Brief_web.pdf

Updated

6 years ago
Keywords: needURLs
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> 2 	http://ard.bmj.com/content/49/4/212.3.full.pdf

Haven't crashed yet with the above URL. However, on Firefox 19.0a2 2012-12-19 I am getting a slow script warning when doing some rapid zooming behaviour (ie. scroll zoom to 400% then out to 127%, then out to 40% and wait).

Slow script warning is on resource://pdf.js/build/pdf.js:2221

Note: Using the PDF Viewer add-on, not the baked-in PDF viewer.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #3)
> Note: Using the PDF Viewer add-on, not the baked-in PDF viewer.

Disabling the PDF Viewer add-on and just using the baked-in functionality gets the same result so this might be a moot point.
Tried the same behaviour in comment 3 with the following:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:1984:126:0020:0026:EN:PDF

After a couple slow script warnings, I clicked the titlebar and Aurora went into "not responding" mode. A few seconds later my screen just went black and my hard drive is thrashing. I had to hard reset my computer.
I'm seeing other slow script warning references in PDF.js. Line 2221, 2219, 3337 are all common.
I managed to trigger a crash. I loaded a few of the PDFs in different tabs, did various scrolling, then turned off Hardware Acceleration in Options. I experienced some considerable hanging and then a crash:

https://crash-stats.mozilla.com/report/index/bp-bd5c9507-5eef-46e9-af52-d1b082121220

Doesn't look like the same signature though. That signature is correlated to bug 726206.
Got a crash again with another signature:
https://crash-stats.mozilla.com/report/index/bp-7050ed3e-9d1e-4519-9259-8cced2121220
(this crash seems correlated to bug 803568 and bug 800523)

This time it was as simple as:
1. Enable hardware acceleration
2. Load http://ard.bmj.com/content/49/4/212.3.full.pdf
3. Scroll mouse to zoom into 400%
4. While PDF is loading, disabled hardware acceleration
> Crash

I can keep banging on this tomorrow but it does seem that there is some general stability issues with PDF.js in Aurora.
CCing :roc to get some help with further investigation here as it could be a canvas issue as reported in the bug.
Turning off HWA while PDF.js is running is likely to be the cause of these crashes in comments #7 and #8.

I wouldn't have thought users would do that very often, I doubt that's the cause of this bug. But we should look into it anyway.
I'm not able to reproduce a crash following the steps in comment #8.

Comment 12

6 years ago
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8)
> I can keep banging on this tomorrow but it does seem that there is some
> general stability issues with PDF.js in Aurora.

Did you find more STR there? Do the ones you provided still end up crashing? Looks like roc couldn't reproduce with those.
Flags: needinfo?(anthony.s.hughes)
The only scenario I've been able to create crashes with is turning on/off HWA while a PDF is loading. The only scenario I've been able to create a slow-script warning is with rapid zooming. I've failed to reproduce any conditions which reproduce the crash signature in this bug.

I'm unassigning myself from this bug because I've spent too much time on this already and haven't got anywhere; that and I have more critical work that needs my attention. Unless someone can come up with some more concrete leads for QA to follow, I fear we won't make any headway here.
Flags: needinfo?(anthony.s.hughes)
Keywords: qawanted
QA Contact: anthony.s.hughes
Yury and I also tried to reproduce this.  I wasn't able to get any crashes from any of the PDFs above.  I believe Yury was able to get a crash, but it had a different signature than this bug.

Comment 15

6 years ago
Given we may be trying to ship PDF.js with 19, we really should investigate that in this beta cycle. Is there any instrumentation we could put into an early beta?
Milan - without STR (despite QA testing), how can we move this bug in the direction of resolution? This is our #41 top crasher, which is particularly high given it's only occurring when PDFs are opened.
Assignee: nobody → milan

Comment 17

6 years ago
This is #41 on 19.0b1 as Alex mentions, and viewing PDFs is pretty rarely-used functionality, so if this is only happening with PDF.js, that makes me nervous.
(In reply to Alex Keybl [:akeybl] from comment #16)
> Milan - without STR (despite QA testing), how can we move this bug in the
> direction of resolution? This is our #41 top crasher, which is particularly
> high given it's only occurring when PDFs are opened.

Could it be related/dup of 803568?  I know the signatures aren't exactly matching, but they look suspiciously alike.

Comment 19

6 years ago
(In reply to Milan Sreckovic [:milan] from comment #18)
> Could it be related/dup of 803568?  I know the signatures aren't exactly
> matching, but they look suspiciously alike.

I think you should know better than any of us if it could be the same, but given that this is D2D and the other cairo and both are something with copying surfaces, there is some similarity, I guess (as a non-coder who has no clue how gfx works other that what I remember from bugs and blogs).

That said, if your patched over there in bug 803568 are cairo-only, I'd really wonder if they'd fix this D2D-related crash, unless one is using the other in some way.
You're right in that these are probably different.  Part of the fix for 803568 is Cairo specific (make sure we catch the error and propagate the error code up), and part of it is in the common 2D canvas code, dealing with the error code - it's the later that made me think these could be related, together with the rapid zooming mentioned in Comment#13.  Groping in the dark :-)
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8)
> Got a crash again with another signature:
> https://crash-stats.mozilla.com/report/index/bp-7050ed3e-9d1e-4519-9259-
> 8cced2121220
> (this crash seems correlated to bug 803568 and bug 800523)
> 
> This time it was as simple as:
> 1. Enable hardware acceleration
> 2. Load http://ard.bmj.com/content/49/4/212.3.full.pdf
> 3. Scroll mouse to zoom into 400%
> 4. While PDF is loading, disabled hardware acceleration
> > Crash
> 
> I can keep banging on this tomorrow but it does seem that there is some
> general stability issues with PDF.js in Aurora.

Is this still on Windows?  I find the PDF loading not letting me open the options dialog, and the options dialog seems to be modal on Windows, so I can't "pre-open" the window.  Or are you disabling HW acceleration outside the Firefox options?
Now that the fix for 803568 is on central, it'd be interesting to see if this crash still shows up.
(Reporter)

Comment 23

6 years ago
(In reply to Milan Sreckovic [:milan] from comment #22)
> Now that the fix for 803568 is on central, it'd be interesting to see if
> this crash still shows up.
There have been no crashes since 21.0a1/20130119 (the fix of bug 803568 landed in 21.0a1/20130120 - see https://crash-stats.mozilla.com/report/list?version=Firefox%3A21.0a1&query_search=signature&range_value=4&range_unit=weeks&signature=mozilla%3A%3Agfx%3A%3ADrawTargetD2D%3A%3ACopySurface%28mozilla%3A%3Agfx%3A%3ASourceSurface*%2C%20mozilla%3A%3Agfx%3A%3AIntRect%20const%26%2C%20mozilla%3A%3Agfx%3A%3AIntPoint%20const%26%29) but it was a low volume in Nightly so it's too soon to conclude.
Bug 803568 was uplifted as part of FF19b3. I don't see any crashes in that version.
status-firefox19: affected → fixed
status-firefox20: affected → fixed
(Reporter)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 803568
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
I was unable to crash the FF. I tested on latest nightly and aurora, FF 19 beta 4.
After I zoom in and out I still receive those script errors. "Script: resource://pdf.js/build/pdf.js:2261" 2241, 327, 329, 327.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8)
> Got a crash again with another signature:
> https://crash-stats.mozilla.com/report/index/bp-7050ed3e-9d1e-4519-9259-
> 8cced2121220
> (this crash seems correlated to bug 803568 and bug 800523)
> 
> This time it was as simple as:
> 1. Enable hardware acceleration
> 2. Load http://ard.bmj.com/content/49/4/212.3.full.pdf
> 3. Scroll mouse to zoom into 400%
> 4. While PDF is loading, disabled hardware acceleration
> > Crash
> 
> I can keep banging on this tomorrow but it does seem that there is some
> general stability issues with PDF.js in Aurora.

Using the above STR I get the same error scripts, no crash and the first page completely black, the second page blank and loading and the third page is loaded. When zoomed out to 54% the first and the third page loads, the second is still loading.

Comment 26

6 years ago
According to the comments above, there is no reliable way of reproducing this bug, so I verified it by checking Socorro:
https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=mozilla%3A%3Agfx%3A%3ADrawTargetD2D%3A%3ACopySurface%28mozilla%3A%3Agfx%3A%3ASourceSurface%2A%2C%20mozilla%3A%3Agfx%3A%3AIntRect%20const%26%2C%20mozilla%3A%3Agfx%3A%3AIntPoint%20const%26%29

There are no post-fix crashes on Firefox 19, 20, and 21.
Status: RESOLVED → VERIFIED
status-firefox19: fixed → verified
status-firefox20: fixed → verified
You need to log in before you can comment on or make changes to this bug.