crash in msvcr120.dll@0xf20c via mozilla::gfx::CopyToImageSurface

RESOLVED DUPLICATE of bug 1133119

Status

()

defect
--
critical
RESOLVED DUPLICATE of bug 1133119
4 years ago
4 years ago

People

(Reporter: andreasjunghw, Unassigned)

Tracking

({crash, topcrash-win})

37 Branch
x86_64
Windows 8.1
Points:
---

Firefox Tracking Flags

(firefox38+ wontfix, firefox39+ ?, firefox40 ?)

Details

(Whiteboard: [gfx-noted], crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

Since I updated to Firefox 37.0.1 I get this crash often when opening a relatively large number of tabs.

I'm not really an expert in using an debugger but msvcr120.dll@0xf20c is apparently MSVCR120!memcpy+0x2a

bp-34d692fc-89dd-437c-81f5-acb802150409
bp-eb915125-783e-430f-a36b-693f12150408
bp-6961b9c8-1bbf-47e6-b4b5-c57bf2150406
bp-c8ec2537-ce9c-4a18-ba77-da6482150410
(Reporter)

Updated

4 years ago
Crash Signature: [@ msvcr120.dll@0xf20c ]
(Reporter)

Comment 1

4 years ago
I was able to catch the crash directly in windbg, see attachment.
Windows 8.1

My STR here on 38 beta (bug 1102612 landed on the April 7th, but the latest has been built on the 9th):

1. Start a new conversation in Loop.
2. Enable tab sharing.
3. In the notification bar about sharing, click on the dropdown next to the OK button.
Actual result: At the latest on clicking the dropdown a second time, the application or the screen of the whole OS will freeze. If the menu opens, the other menu option will be only black surface or the style of the window will break (see attached screenshot).

https://crash-stats.mozilla.com/report/index/78f714e8-a82b-424a-8b93-364122150412
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1102612
Posted file testcanvas.html (obsolete) —
A large canvas like this trivially triggers this crash for me.
Posted file testcanvas.html
Uploaded the wrong version.
Attachment #8591892 - Attachment is obsolete: true
[Tracking Requested - why for this release]: 37.0.1 has a large number of crashes (more than 18000 in 28 days)

Reproduced the crash on Firefox 38 beta 5, Win 8 32-bit while playing some YouTube videos with flash (YouTube™ Flash® Player 1.2) and opening about:addons tab.

https://crash-stats.mozilla.com/report/index/bp-4c13aab8-faa0-4935-accf-3aab42150417
Whiteboard: [gfx-noted]
Important crash, tracking.
Milan, do you know who could help on this? Thanks
Flags: needinfo?(milan)
I want to say this is the same issue as bug 1133119, but the experts should confirm.
(In reply to David Major [:dmajor] from comment #7)
> I want to say this is the same issue as bug 1133119, but the experts should
> confirm.

Crashes that do come through gfx::CopyToImageSurface, yeah, I'd say that's probably bug 1133119, which was fixed in 39, and not uplifted.  My feeble searching skills get me to all memcpy crashes, and those are many and differing, but can somebody with better skills check if we have gfx::CopyToImageSurface related crashes in (late) 39 and 40?  If that's clear, we should probably ask for the bug 1133119 uplift to 38.
Flags: needinfo?(milan)
The numbers are too small for me to make a confident statement about nightlies 39 and 40.

But from what I can tell, around 85% of the memcpy crashes on 38 beta are via gfx::CopyToImageSurface. Sounds like an uplift would help!

Updated

4 years ago
Keywords: crash
I asked for an uplift in bug 1153558.
(In reply to Sylvestre Ledru [:sylvestre] from comment #10)
> I asked for an uplift in bug 1153558.

Sylvestre meant bug 1133119.
sorry, doing too many things in parallel :)

Updated

4 years ago
Keywords: topcrash-win
Do we still have this issue then?

Comment 14

4 years ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #13)
> Do we still have this issue then?

The signature has moved way down in 38.0b9 for sure, so my guess is that this specific issue has been fixed with bug 1133119 and what's left is other stacks that happen to end up in memcpy, which is this signature.
OK, Thanks. I am afraid it is too late for 38. Tracking it for 39.
The title of this bug is "crash in msvcr120.dll@0xf20c via mozilla::gfx::CopyToImageSurface". Those are fixed. I think we should either resolve this, or re-title it to reflect the fact that they're from other callers. Personally I lean towards the former, because the volume is so low that we wouldn't file a fresh bug for this.

Comment 17

4 years ago
I agree but with the current signature can't actually verify that the assumption that all of those are fixed is actually true.

Updated

4 years ago
Depends on: 1161067
(Reporter)

Updated

4 years ago
Crash Signature: [@ msvcr120.dll@0xf20c ] → [@ msvcr120.dll@0xf20c ] [@ msvcr120.dll@0xf20c | mozilla::gfx::CopyToImageSurface(unsigned char*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::SurfaceFormat) ]
With bug 1161067 fixed, what's next on this bug?
Flags: needinfo?(kairo)

Comment 19

4 years ago
(In reply to Milan Sreckovic [:milan] from comment #18)
> With bug 1161067 fixed, what's next on this bug?

Now we can actually verify that this instance is fixed. :)

Or rather, that it's a dupe. Marking as such as there are no crashes with the new signature in later builds than 38.0b6. \o/
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(kairo)
Resolution: --- → DUPLICATE
Duplicate of bug: 1133119
You need to log in before you can comment on or make changes to this bug.