Closed Bug 734921 Opened 12 years ago Closed 12 years ago

Startup Crash @ _moz_cairo_destroy

Categories

(Core :: Graphics, defect)

12 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 773097
Tracking Status
firefox14 - affected
firefox15 - affected
firefox16 - affected
firefox17 - affected

People

(Reporter: marcia, Assigned: joe)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [startupcrash])

Crash Data

Attachments

(1 file)

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
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
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]
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.
Keywords: topcrash
Summary: Firefox Crash [@ _moz_cairo_destroy ] → Startup Crash @ _moz_cairo_destroy
There are no interesting correlations: no extensions, no specific DLL versions.
Keywords: needURLs
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: → 773097
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
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
(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.
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
@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.
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
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::BuildContaine…
I have an affected user at https://support.mozilla.org/en-US/questions/934203. Is there any investigation we need to be doing here?
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
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.
Crash Signature: [@ _moz_cairo_destroy ] [@ je_free | mozilla::`anonymous namespace''::ContainerState::FindThebesLayerFor(nsDisplayItem*, nsIntRect const&, nsIntRect const&, mozilla::FrameLayerBuilder::Clip const& → [@ _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&
This now is easily the #1 topcrash, amounting 53% (!!!) of all 14.0.1 crashes yesterday.
Crash Signature: nsIFrame*)] [@ mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::FrameLayerBuilder::ContainerParameters const&, gfx3DMatrix const*)] → nsIFrame*)] [@ mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::FrameLayerBuilder::ContainerParameters const& gfx3DMatrix const*)] [@ nsTA…
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& nsIFrame*)] … → [@ _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::FrameLayerBuilder::…
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.
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
(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
about_support information in an textfile
(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
Crash Signature: mozilla::FrameLayerBuilder::Clip&)] [@ PL_DHashTableOperate | nsTHashtable<mozilla::FrameLayerBuilder::ThebesLayerItemsEntry>::PutEntry(mozilla::layers::ThebesLayer*)] → mozilla::FrameLayerBuilder::Clip&)] [@ PL_DHashTableOperate | nsTHashtable<mozilla::FrameLayerBuilder::ThebesLayerItemsEntry>::PutEntry(mozilla::layers::ThebesLayer*)] [@ nsTArray_base<nsTArrayDefaultAllocator>::SwapArrayElements<nsTArrayDefaultAllocato…
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::FrameLayerBuilder::… → [@ _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* nsIntRec…
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.
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
Closed: 12 years ago
Resolution: --- → DUPLICATE
See Also: 773097
taking the tracking over to bug 773097 as well then.
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
(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.

Attachment

General

Creator:
Created:
Updated:
Size: