921215 - crash in MacIOSurface::GetWidth()

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Martijn Wargers (dead)]

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
etc...

Comment 1

[u279076]

Thanks Martijn, can you try to regress the hang?

Comment 2

[Martijn Wargers (dead)]

Attachment: log.txt

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

[Martijn Wargers (dead)]

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.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Martijn, what about aurora and nightly? Do they behave the same?

Comment 5

[Alex Keybl [:akeybl]]

Over to Milan to help with investigation, and including mbest so that he's in the loop on this Unreal Engine related regression.

Comment 6

[Kyle Wooten]

Thanks!

Comment 7

[u279076]

Martijn, can you please investigate the regression window further using the Firefox 25 Nightly builds?

Comment 8

[Martijn Wargers (dead)]

I can try and find a regression window for the hang, the crash seemed to be a one time only event.

Comment 9

[Martijn Wargers (dead)]

I'm afraid, I can't seem to reproduce this hang anymore in any build, whatsoever (tried Firefox 24, 25 and trunk).

Comment 10

[Alex Keybl [:akeybl]]

WFM in that case. Thanks Martijn!

Comment 11

[Martijn Wargers (dead)]

Well, I haven't been able to reproduce, but it seems to me, it should be still there.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 13

[u279076]

More reports:
https://crash-stats.mozilla.com/query/?query_type=simple&query=MacIOSurface%3A%3AGetWidth%28%29

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.

Comment 14

[u480271]

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.

Comment 15

[u480271]

Attachment: Handle being passed NULL ptr for either surface or gl to SharedSurface_IOSurface::Create by returning NULL.

Matt, Does this look right?

Comment 16

[u480271]

https://tbpl.mozilla.org/?tree=Try&rev=45acaf889050

Comment 17

[Matt Woodrow (:mattwoodrow)]

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.

Comment 18

[u480271]

(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.

Comment 19

[u480271]

Attachment: Handle being passed NULL ptr for either surface or gl toSharedSurface_IOSurface::Create by returning NULL.

Updated to follow review comments.

Comment 20

[u480271]

https://tbpl.mozilla.org/?tree=Try&rev=591830a941e2

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1552300c12e3

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1552300c12e3

Comment 23

[u279076]

Martijn, can you please see if this crash reproduces for you in the latest Nightly?

Comment 24

[Martijn Wargers (dead)]

Sorry, I can't confirm this bug to be fixed or not, this crash was a one time only crash for me.