See url testcase, shortly after opening that url with the b2g browser on my Otoro phone, I get an OS reboot. I submitted the FirefoxOS crash reports, with the dialog at the bottom that I'm seeing after the system reboot. I don't know where you could see those, though. My Otoro phone nr. is 12539.

+cc: jwatt Can you trap the crash on your B2G phone?

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #0) > I submitted the FirefoxOS crash reports, with the dialog at the bottom that > I'm seeing after the system reboot. > I don't know where you could see those, though. My Otoro phone nr. is 12539. You could retrieve the crash ID by connecting your device to a computer with adb and executing this command: adb shell ls -l /data/b2g/mozilla/Crash\ Reports/submitted/ We unfortunately don't have about:crashes on the devices at this time.

Ok, thanks. it doesn't seem like the crash report contains anything useful: https://crash-stats.mozilla.com/report/index/8412b99c-a690-497a-b196-6ca172121126 0 @0x40fb6b4e

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #3) > Ok, thanks. it doesn't seem like the crash report contains anything useful: > https://crash-stats.mozilla.com/report/index/8412b99c-a690-497a-b196- > 6ca172121126 > 0 @0x40fb6b4e We unfortunately have that happen quite a lot right now. Bug 811335 might help improve those cases.

jwatt: please update with a stack trace

Setting priority based on triage discussions. Feel free to decrease priority if you disagree.

I can't reproduce this.

Still reproducable with the latest build on the Otoro phone.

What does "latest build" mean? I'm testing with latest commits on the nightly branch as of this morning.

The latest build that I got an update with. But I guess you have a newer build, so perhaps this can be closed then.

I can reproduce on the 11-29 nightly. Let me retest with my latest build.

Hm, I'm able to reproduce now, for some reason.

(gdb) bt #0 mozilla::gl::TiledTextureImage::GetTileRect (this=0x443492c0) at /home/cjones/mozilla/new-b2g/gecko/gfx/gl/GLContext.cpp:1156 #1 0x40fcfc58 in mozilla::gl::TiledTextureImage::GetSrcTileRect (this=0xffffffff) at /home/cjones/mozilla/new-b2g/gecko/gfx/gl/GLContext.cpp:1165 #2 0x40fd0dc0 in mozilla::gl::TiledTextureImage::DirectUpdate (this=0x443492c0, aSurf=<value optimized out>, aRegion=<value optimized out>, aFrom=...) at /home/cjones/mozilla/new-b2g/gecko/gfx/gl/GLContext.cpp:951 #3 0x40fbbb8c in mozilla::layers::ShadowImageLayerOGL::Swap (this=<value optimized out>, aNewFront=..., aNewBack=0x438e0a18) at /home/cjones/mozilla/new-b2g/gecko/gfx/layers/opengl/ImageLayerOGL.cpp:788 #4 0x40fcec02 in mozilla::layers::ShadowLayersParent::RecvUpdate (this=<value optimized out>, cset=<value optimized out>, targetConfig=<value optimized out>, isFirstPaint=<value optimized out>, reply=0x438e0bdc) at /home/cjones/mozilla/new-b2g/gecko/gfx/layers/ipc/ShadowLayersParent.cpp:447 #5 0x40e99c22 in mozilla::layers::PLayersParent::OnMessageReceived (this=0x43df4940, __msg=<value optimized out>, __reply=@0x438e0cfc) at /home/cjones/mozilla/new-b2g/objdir-gecko/ipc/ipdl/PLayersParent.cpp:508 #6 0x40e93cc2 in mozilla::layers::PCompositorParent::OnMessageReceived (this=0x4ce5b960, __msg=..., __reply=@0x438e0cfc) at /home/cjones/mozilla/new-b2g/objdir-gecko/ipc/ipdl/PCompositorParent.cpp:393 (gdb) p *mImages.mHdr $11 = { static sEmptyHdr = { static sEmptyHdr = <same as static member of an already seen type>, mLength = 0, mCapacity = 0, mIsAutoArray = 0 }, mLength = 0, mCapacity = 0, mIsAutoArray = 0 } We're on the compositor thread, and a ShadowImageLayer doesn't have any images allocated to its TextureImage. Very odd ...

This is happening because we're trying to use a 0x0 buffer for the image layer, and TextureImage doesn't like that. This is easy enough to "fix", but is it legal to have a 0x0 image to begin with?

It's strange, but I think it should be legal. I don't think it's a good idea to require non-zero sizes in APIs.

This doesn't crash in fennec, but the rendering is really garbled so another bug might be hiding this.

Pretty gross, but if this is something we want to allow, we should be flexible at the lowest level possible.

Comment on attachment 687959 [details] [diff] [review] Guard against TiledTextureImage with dimensions of 0 Review of attachment 687959 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/gl/GLContext.cpp @@ +923,4 @@ > { > mTileSize = (!(aFlags & TextureImage::ForceSingleTile) && mGL->WantsSmallTiles()) > ? 256 : mGL->GetMaxTextureSize(); > + if (aSize.width != 0 && aSize.height != 0) { Having an IsEmpty() on BaseSize might be nice here.

Comment on attachment 687957 [details] [diff] [review] Test for bug 813372 Missing a qref? This appears to be an empty patch :)

hg conveniently forwarded the changes to a qnew patch that I later qrm'd. Thanks hg!

(In reply to Matt Woodrow (:mattwoodrow) from comment #18) > Comment on attachment 687959 [details] [diff] [review] > Guard against TiledTextureImage with dimensions of 0 > > Review of attachment 687959 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: gfx/gl/GLContext.cpp > @@ +923,4 @@ > > { > > mTileSize = (!(aFlags & TextureImage::ForceSingleTile) && mGL->WantsSmallTiles()) > > ? 256 : mGL->GetMaxTextureSize(); > > + if (aSize.width != 0 && aSize.height != 0) { > > Having an IsEmpty() on BaseSize might be nice here. I agree. Filed bug 817846 for the bikeshedding.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3932ed990e9b https://hg.mozilla.org/integration/mozilla-inbound/rev/54731c5fdc2c

https://hg.mozilla.org/mozilla-central/rev/3932ed990e9b https://hg.mozilla.org/mozilla-central/rev/54731c5fdc2c

https://hg.mozilla.org/releases/mozilla-aurora/rev/bebce27634df https://hg.mozilla.org/releases/mozilla-aurora/rev/317a6f1796c3 https://hg.mozilla.org/releases/mozilla-beta/rev/f42e152981d0 https://hg.mozilla.org/releases/mozilla-beta/rev/510194c878d3

removing qawanted; cjones did reproduce this and there are fixes in place.