b2g process crash with this testcase, using -moz-transition

RESOLVED FIXED in Firefox 18

Status

()

defect
P1
critical
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: martijn.martijn, Assigned: cjones)

Tracking

({crash, testcase})

19 Branch
mozilla20
ARM
Gonk (Firefox OS)
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

Details

()

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

7 years ago
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.
blocking-basecamp: --- → ?
Component: General → Layout
Product: Boot2Gecko → Core
Version: unspecified → 19 Branch

Updated

7 years ago
blocking-basecamp: ? → +
+cc: jwatt

Can you trap the crash on your B2G phone?
Assignee: nobody → jwatt
blocking-basecamp: + → ?
blocking-basecamp: ? → +

Comment 2

7 years ago
(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.
Reporter

Comment 3

7 years ago
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

Comment 4

7 years ago
(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.
Priority: -- → P1
Summary: Crash/OS reboot with this testcase, using -moz-transition → b2g process crash with this testcase, using -moz-transition
I can't reproduce this.
Keywords: qawanted
Reporter

Comment 8

7 years ago
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.
Reporter

Comment 10

7 years ago
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.
Assignee: jwatt → jones.chris.g
(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?
Flags: needinfo?(roc)
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.
Flags: needinfo?(roc)
Posted patch Test for bug 813372 (obsolete) — Splinter Review
This doesn't crash in fennec, but the rendering is really garbled so another bug might be hiding this.
Attachment #687957 - Flags: review?(matt.woodrow)
Pretty gross, but if this is something we want to allow, we should be flexible at the lowest level possible.
Attachment #687959 - Flags: review?(matt.woodrow)
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.
Attachment #687959 - Flags: review?(matt.woodrow) → review+
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!
Attachment #687957 - Attachment is obsolete: true
Attachment #687957 - Flags: review?(matt.woodrow)
Attachment #688007 - Flags: review?(matt.woodrow)
(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.
Attachment #688007 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/3932ed990e9b
https://hg.mozilla.org/mozilla-central/rev/54731c5fdc2c
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
removing qawanted; cjones did reproduce this and there are fixes in place.
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.