bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

crash in MacIOSurface::GetWidth()

RESOLVED FIXED in mozilla28



5 years ago
4 years ago


(Reporter: Martijn Wargers (zombie), Assigned: kamidphish)


({crash, hang})

Mac OS X
crash, hang

Firefox Tracking Flags

(firefox24 unaffected, firefox25- affected, firefox26 affected, firefox27 affected)


(Whiteboard: [qa-], crash signature, URL)


(2 attachments, 1 obsolete attachment)



5 years ago
I got this crash on my Macbook Pro, using MacOsX 10.7.5, using Firefox 25.
I could not reproduce this crash, I only got it the first time I visited the site. Afterwards, I get hangs/freezes on that site.

What I did:
1. Load http://www.unrealengine.com/html5/ in a new tab
2. Click the 'Play' button and wait for the data to download (might take a couple minutes)
3. If you get a warning about storing offline data, click 'Allow' and wait a couple more minutes for some more loading
4. Go to full screen (with the Apple full screen button on the top right).

This bug was filed from the Socorro interface and is 
report bp-7d59f361-fe46-47b7-ad9e-856e82130926.
0 	XUL 	MacIOSurface::GetWidth() 	gfx/2d/QuartzSupport.mm
1 	XUL 	mozilla::gl::SurfaceFactory_IOSurface::CreateShared(nsIntSize const&) 	gfx/gl/SharedSurfaceIO.cpp
2 	XUL 	mozilla::gfx::SurfaceStream_TripleBuffer::SwapProducer(mozilla::gfx::SurfaceFactory*, nsIntSize const&) 	gfx/gl/SurfaceStream.cpp
3 	XUL 	mozilla::gl::GLScreenBuffer::PublishFrame(nsIntSize const&) 	gfx/gl/GLScreenBuffer.cpp
4 	XUL 	mozilla::gl::GLContext::PublishFrame() 	gfx/gl/GLContext.cpp
5 	XUL 	mozilla::WebGLContext::PresentScreenBuffer() 	content/canvas/src/WebGLContext.cpp
6 	XUL 	mozilla::WebGLContextUserData::PreTransactionCallback(void*) 	content/canvas/src/WebGLContext.cpp
7 	XUL 	mozilla::layers::ClientCanvasLayer::RenderLayer() 	gfx/layers/Layers.h
8 	XUL 	ClientContainerLayer::RenderLayer() 	gfx/layers/client/ClientContainerLayer.h
9 	XUL 	ClientContainerLayer::RenderLayer() 	gfx/layers/client/ClientContainerLayer.h
10 	XUL 	mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/client/ClientLayerManager.cpp
Thanks Martijn, can you try to regress the hang?
Keywords: regressionwindow-wanted

Comment 2

5 years ago
Created attachment 810787 [details]

This is a log of the hang.
I haven't been able to reproduce the hang in a clean profile yet, so this might be extension related or something like that.

Comment 3

5 years ago
Ok, I managed to get the hang also in a clean profile in Firefox25.
I haven't been able to get the hang (yet?) in Firefox24.
Martijn, what about aurora and nightly? Do they behave the same?
status-firefox25: --- → affected
status-firefox26: --- → ?
status-firefox27: --- → ?
tracking-firefox25: --- → ?

Comment 5

5 years ago
Over to Milan to help with investigation, and including mbest so that he's in the loop on this Unreal Engine related regression.
Assignee: nobody → milan
status-firefox24: --- → unaffected
tracking-firefox25: ? → +

Comment 6

5 years ago


5 years ago
Keywords: qawanted
Martijn, can you please investigate the regression window further using the Firefox 25 Nightly builds?
Flags: needinfo?(martijn.martijn)

Comment 8

5 years ago
I can try and find a regression window for the hang, the crash seemed to be a one time only event.
Flags: needinfo?(martijn.martijn)
Keywords: hang


5 years ago
Flags: needinfo?(martijn.martijn)

Comment 9

5 years ago
I'm afraid, I can't seem to reproduce this hang anymore in any build, whatsoever (tried Firefox 24, 25 and trunk).
Flags: needinfo?(martijn.martijn)
WFM in that case. Thanks Martijn!
Last Resolved: 5 years ago
tracking-firefox25: + → -
Keywords: qawanted, regressionwindow-wanted
Resolution: --- → WORKSFORME

Comment 11

5 years ago
Well, I haven't been able to reproduce, but it seems to me, it should be still there.
Absolutely. I can see crash reports with a yesterdays build, which makes it hard for me to believe that this crash has been fixed as of today.

See https://crash-stats.mozilla.com/report/index/6ee5db6f-00ec-420d-b53a-7c2d32131009
Resolution: WORKSFORME → ---
More reports:

While this does have more reports in Firefox 25, 26, and 27. At 12 reports in the last week across all versions this is well below our threshold for tracking and assigning investigative resources at this time.
status-firefox26: ? → affected
status-firefox27: ? → affected
Assignee: milan → dglastonbury
In response to the crash reports in Comment 13, a quick code review suggests that in:

/* static */ SharedSurface_IOSurface*
SharedSurface_IOSurface::Create(MacIOSurface* surface, GLContext *gl, bool hasAlpha)
  gfxIntSize size(surface->GetWidth(), surface->GetHeight());

surface is NULL. I'll add handling code for this case.
Created attachment 8341401 [details] [diff] [review]
Handle being passed NULL ptr for either surface or gl to SharedSurface_IOSurface::Create by returning NULL.

Matt, Does this look right?
Attachment #8341401 - Flags: review?(matt.woodrow)
Comment on attachment 8341401 [details] [diff] [review]
Handle being passed NULL ptr for either surface or gl to SharedSurface_IOSurface::Create by returning NULL.

Review of attachment 8341401 [details] [diff] [review]:

::: gfx/gl/SharedSurfaceIO.cpp
@@ +16,5 @@
>  /* static */ SharedSurface_IOSurface*
>  SharedSurface_IOSurface::Create(MacIOSurface* surface, GLContext *gl, bool hasAlpha)
>  {
> +    if (!surface) {

Might as well move this into the caller (at the bottom of this file), since that's where the failure to create the MacIOSurface happens.

@@ +21,5 @@
> +        NS_WARNING("SharedSurface_IOSurface::Create: surface passed NULL.");
> +        return nullptr;
> +    }
> +
> +    if (!gl) {

Does this ever happen? I think this should be a hard assert.
(In reply to Matt Woodrow (:mattwoodrow) from comment #17)
> Comment on attachment 8341401 [details] [diff] [review]
> @@ +21,5 @@
> > +        NS_WARNING("SharedSurface_IOSurface::Create: surface passed NULL.");
> > +        return nullptr;
> > +    }
> > +
> > +    if (!gl) {
> Does this ever happen? I think this should be a hard assert.

I added it just for completeness.
Created attachment 8341479 [details] [diff] [review]
Handle being passed NULL ptr for either surface or gl toSharedSurface_IOSurface::Create by returning NULL.

Updated to follow review comments.
Attachment #8341479 - Flags: review?(matt.woodrow)
Attachment #8341401 - Attachment is obsolete: true
Attachment #8341401 - Flags: review?(matt.woodrow)
Attachment #8341479 - Flags: review?(matt.woodrow) → review+
Keywords: checkin-needed
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Martijn, can you please see if this crash reproduces for you in the latest Nightly?
Flags: needinfo?(martijn.martijn)

Comment 24

4 years ago
Sorry, I can't confirm this bug to be fixed or not, this crash was a one time only crash for me.
Flags: needinfo?(martijn.martijn)
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.