The default bug view has changed. See this FAQ.

Startup Crash @ _moz_cairo_destroy

RESOLVED DUPLICATE of bug 773097

Status

()

Core
Graphics
--
critical
RESOLVED DUPLICATE of bug 773097
5 years ago
5 years ago

People

(Reporter: marcia, Assigned: Joe Drew (not getting mail))

Tracking

({crash, regression, topcrash})

12 Branch
x86
Windows XP
crash, regression, topcrash
Points:
---

Firefox Tracking Flags

(firefox14- affected, firefox15- affected, firefox16- affected, firefox17- affected)

Details

(Whiteboard: [startupcrash], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Seen while looking at Aurora Crash stats.  https://crash-stats.mozilla.com/report/list?signature=_moz_cairo_destroy to the crashes which have happened in other versions but seems higher in Aurora.

https://crash-stats.mozilla.com/report/index/9fe13690-443e-4164-8109-392282120306

Frame Module Signature [Expand] Source 0 xul.dll _moz_cairo_destroy gfx/cairo/cairo/src/cairo.c:434 1 xul.dll gfxContext::~gfxContext 2 xul.dll gfxContext::`scalar deleting destructor' 3 xul.dll nsRefPtr<gfxContext>::~nsRefPtr<gfxContext> 4 xul.dll xul.dll@0x13db1f 5 xul.dll mozilla::layers::ThebesLayerD3D10::DrawRegion gfx/layers/d3d10/ThebesLayerD3D10.cpp:426 6 nspr4.dll nspr4.dll@0x909f 7 xul.dll mozilla::layers::ThebesLayerD3D10::Validate gfx/layers/d3d10/ThebesLayerD3D10.cpp:287
(Reporter)

Comment 1

5 years ago
Apologies for the cut and paste - I am running on an early seed of 10.8 and apparently it is not working well:


Frame	Module	Signature [Expand]	Source
0	xul.dll	_moz_cairo_destroy	gfx/cairo/cairo/src/cairo.c:434
1	xul.dll	gfxContext::~gfxContext	
2	xul.dll	gfxContext::`scalar deleting destructor'	
3	xul.dll	nsRefPtr<gfxContext>::~nsRefPtr<gfxContext>	
4	xul.dll	xul.dll@0x13db1f	
5	xul.dll	mozilla::layers::ThebesLayerD3D10::DrawRegion	gfx/layers/d3d10/ThebesLayerD3D10.cpp:426
6	nspr4.dll	nspr4.dll@0x909f	
7	xul.dll	mozilla::layers::ThebesLayerD3D10::Validate	gfx/layers/d3d10/ThebesLayerD3D10.cpp:287

Comment 2

5 years ago
In 12.0a2 and 13.0a1, it's a startup crash which isn't the case in 10.0.2 and 11.0beta.

The stack for the startup case is different from the one in comment 1 and looks like:
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	_moz_cairo_destroy 	gfx/cairo/cairo/src/cairo.c:439
1 	xul.dll 	gfxContext::~gfxContext 	
2 	xul.dll 	gfxContext::Release 	obj-firefox/dist/include/gfxContext.h:74
3 	xul.dll 	nsWindow::OnPaint 	widget/windows/nsWindowGfx.cpp:450
...

It first appeared in 12.0a1/20120108. The regression range might be (hard to be sure for a startup crash):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5a446202be5f&tochange=cf8c9f9aeefc
Component: Graphics → Widget: Win32
Keywords: regression
QA Contact: thebes → win32
Whiteboard: [startupcrash]

Comment 3

5 years ago
It's #2 top crasher in 14.0.1, #1 in 15.0b3 and #3 in 16.0a2.
17.0a1 is unaffected.

There were only 25 crashes on August 6th, so it's caused by a DLL or extension update. I will provide today's correlations as soon as there are available.
status-firefox14: --- → affected
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → unaffected
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Keywords: topcrash
Summary: Firefox Crash [@ _moz_cairo_destroy ] → Startup Crash @ _moz_cairo_destroy

Comment 4

5 years ago
There are no interesting correlations: no extensions, no specific DLL versions.
Keywords: needURLs

Comment 5

5 years ago
60% of crashes happen on Windows XP.

Here are some correlations per module:
  _moz_cairo_destroy|EXCEPTION_ACCESS_VIOLATION_READ (44718 crashes)
    100% (44715/44718) vs.  37% (95988/258368) d3d9.dll
    100% (44633/44718) vs.  37% (95823/258368) d3d8thk.dll
OS: Windows 7 → Windows XP
See Also: → bug 773097

Comment 6

5 years ago
I just had someone report that disabling the Java Quick Starter extension fixed this crash for them https://support.mozilla.org/en-US/questions/934157

Comment 7

5 years ago
The signature in this bug, the one in bug 773097, as well as some other gfx-related ones have been radically exploding in yesterday's data (2012-08-06), see https://crash-analysis.mozilla.com/rkaiser/2012-08-06/2012-08-06.firefox.14.explosiveness.html

Comment 8

5 years ago
(In reply to Verdi from comment #6)
> I just had someone report that disabling the Java Quick Starter extension
> fixed this crash for them https://support.mozilla.org/en-US/questions/934157
I don't think it's caused by the JQS extension because the JQS version hasn't changed, still 1.0.

Comment 9

5 years ago
Top 10 URLs:

1880 	http://www.google.com.tr/
1285 	http://www.google.de/
1014 	http://www.google.fr/
958 	http://www.google.co.id/
900 	about:blank
816 	http://www.google.es/
789 	http://www.google.com.au/
567 	http://www.google.pl/
545 	http://www.google.it/
541 	http://www.google.co.th/

This is followed by a long list of other Google URLs. Is there some Google Doodle today or yesterday that could be causing this?
OTOH, this could just be because it's a startup crash and people have set Google as the startup page.
Keywords: needURLs

Comment 10

5 years ago
@Rober Kaiser:
Your guess seems right to me.

I had 4 occasions of this Bug today on 4 different machines:
- all under Windows XP
- all FF 14.01
- all with integrated Intel Graphics (2 on Notebooks, 2 on Desktops)
- all with www.google.de as startup page (with the Olympic-Sprinter-Doodle-Game today)

After reset of FF with the upcoming FF-Tool und activation of the Standard-Mozilla-Google-Startpage, the Browser comes up again. We could browse www.google.de within FF, but after activating the native www.google.de as startup-page the crash comes up again at startup of FF!

After that I only delete the startuppage of FF in Prefs.js and all functioned normal again! Browsing to google works again after startup.

This behaviour was reproducable!

My guess: Because there are many identical configured Systems (without Intel GFX!) lacking a startup crash, I point to the integrated Intel-Graphics in conjunction with the FF-initialization.
But that's only an uneducated guess from me.

Updated

5 years ago
Component: Widget: Win32 → Graphics
Should this investigation go further than today, the url for the doodle itself is https://www.google.com/doodles/hurdles-2012
(Reporter)

Comment 12

5 years ago
Adding the trunk signatures to this bug for tracking purposes since this bug is the top crash in volume - they appear to be the same startup crash with all Google URLs.
Crash Signature: [@ _moz_cairo_destroy ] → [@ _moz_cairo_destroy ] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFrame*)] [@ mozilla::FrameLayerBuilder::BuildC&hellip;

Updated

5 years ago
status-firefox17: unaffected → affected
I have an affected user at https://support.mozilla.org/en-US/questions/934203. Is there any investigation we need to be doing here?
(Reporter)

Comment 14

5 years ago
Joe is able to repro in Bug 773097 Comment 6, so I think we are okay here.

(In reply to Tyler Downer [:Tyler] from comment #13)
> I have an affected user at
> https://support.mozilla.org/en-US/questions/934203. Is there any
> investigation we need to be doing here?
Tracking and assigning to Joe (for now, reassign if there's a better candidate).
Assignee: nobody → joe
tracking-firefox14: ? → +
tracking-firefox15: ? → +
tracking-firefox16: ? → +
tracking-firefox17: --- → +

Comment 16

5 years ago
Since only Intel graphics have been mentioned, I'll add that I've been getting this (and 773097) today with a GeForce 9500 GT (recent driver 301.42), XP SP3 32-bit (up to date), and google as my homepage.
(Reporter)

Updated

5 years ago
Crash Signature: [@ _moz_cairo_destroy ] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFrame*)] [@ mozilla::FrameLayerBuilder::BuildC&hellip; → [@ _moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFr&hellip;

Comment 17

5 years ago
This now is easily the #1 topcrash, amounting 53% (!!!) of all 14.0.1 crashes yesterday.
(Reporter)

Updated

5 years ago
Crash Signature: [@ _moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFr&hellip; → [@ _moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFr&hellip;
(Reporter)

Updated

5 years ago
Crash Signature: [@ _moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& nsIFr&hellip; → [@ _moz_cairo_destroy ] [@ moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const& mozilla::FrameLayerBu&hellip;
Seeing this on Win7 (NVidia Geforce 7900 GT) with 14.0.1, but not on Win8RP (Nvidia Geforce GTX 280) with latest Nightly. Both were set to google.com as home page.

Comment 19

5 years ago
I got now(In reply to bloodflash from comment #10)
> @Rober Kaiser:
> Your guess seems right to me.
> 
> I had 4 occasions of this Bug today on 4 different machines:
> - all under Windows XP
> - all FF 14.01
> - all with integrated Intel Graphics (2 on Notebooks, 2 on Desktops)
> - all with www.google.de as startup page (with the
> Olympic-Sprinter-Doodle-Game today)
> 
> After reset of FF with the upcoming FF-Tool und activation of the
> Standard-Mozilla-Google-Startpage, the Browser comes up again. We could
> browse www.google.de within FF, but after activating the native
> www.google.de as startup-page the crash comes up again at startup of FF!
> 
> After that I only delete the startuppage of FF in Prefs.js and all
> functioned normal again! Browsing to google works again after startup.
> 
> This behaviour was reproducable!
> 
> My guess: Because there are many identical configured Systems (without Intel
> GFX!) lacking a startup crash, I point to the integrated Intel-Graphics in
> conjunction with the FF-initialization.
> But that's only an uneducated guess from me.

I can confirm, that the ff startup crashs stopped after changing the default page from google.de (with olympic doodle) to whatever.de. It happend only today...

my system: win7 (x64), ff 14.01, ati radeon hd 5870, catalyst 12.6
(Reporter)

Comment 20

5 years ago
(In reply to Dennis L from comment #19)

Dennis: Can you cut and paste info from about:support here? We are having trouble reproducing the crash.
> 
> I can confirm, that the ff startup crashs stopped after changing the default
> page from google.de (with olympic doodle) to whatever.de. It happend only
> today...
> 
> my system: win7 (x64), ff 14.01, ati radeon hd 5870, catalyst 12.6

Comment 21

5 years ago
Created attachment 650339 [details]
about_support_Dennis-2012-08-08.txt

about_support information in an textfile

Comment 22

5 years ago
(In reply to Marcia Knous [:marcia] from comment #20)

Marcia: Hi, i added the information in the attachement: about_support_Dennis-2012-08-08.txt 

> (In reply to Dennis L from comment #19)
> 
> Dennis: Can you cut and paste info from about:support here? We are having
> trouble reproducing the crash.
> > 
> > I can confirm, that the ff startup crashs stopped after changing the default
> > page from google.de (with olympic doodle) to whatever.de. It happend only
> > today...
> > 
> > my system: win7 (x64), ff 14.01, ati radeon hd 5870, catalyst 12.6
(Reporter)

Updated

5 years ago
Crash Signature: [@ _moz_cairo_destroy ] [@ moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const& mozilla::FrameLayerBu&hellip; → [@ _moz_cairo_destroy ] [@ moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const& mozilla::FrameLayerBu&hellip;
Please see my comments at https://bugzilla.mozilla.org/show_bug.cgi?id=773097#c30 and https://bugzilla.mozilla.org/show_bug.cgi?id=773097#c31 -- they seem related.

Updated

5 years ago
Crash Signature: [@ _moz_cairo_destroy ] [@ moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const& mozilla::FrameLayerBu&hellip; → [@ _moz_cairo_destroy ] [@ moz_cairo_destroy ] [@ _moz_cairo_surface_get_reference_count] [@ _cairo_gstate_restore ] [@ gfxASurface::Release() ] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem* n&hellip;

Updated

5 years ago
Duplicate of this bug: 781459

Comment 25

5 years ago
There is a testcase and crash report link in bug 773097 comment 32, but actually the crash signature is for this bug. Hopefully it can help someone reproduce the crash.

Comment 26

5 years ago
As all the discussion is over there, I'll dupe over to bug 773097 and move all the signatures there.

If this signature appears again after a fix for the bug there has been made, please file a new bug to have a clean discussion. So far,  there has been no fix, so no need to file anything else on this, though, let's consolidate in bug 773097.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 773097

Updated

5 years ago
See Also: bug 773097
taking the tracking over to bug 773097 as well then.
tracking-firefox14: + → -
tracking-firefox15: + → -
tracking-firefox16: + → -
tracking-firefox17: + → -

Comment 28

5 years ago
After installation of beta 15.03 the failure "crash at start up with google.de as start up page" does no more happen. It seems to be solved

Comment 29

5 years ago
(In reply to konzertaufnahmen from comment #28)
> After installation of beta 15.03 the failure "crash at start up with
> google.de as start up page" does no more happen. It seems to be solved
Only doodles from August 8th and 9th had the problem, so it's also solved in 14.0.1.
You need to log in before you can comment on or make changes to this bug.