Closed Bug 813372 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Version:
19 Branch
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20
Project Flags:
blocking-basecamp +
Tracking Flags:
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: martijn.martijn, Assigned: cjones)

References

(
URL
)

Details

(Keywords: crash, testcase)

Attachments

(3 files, 1 obsolete file)

Guard against TiledTextureImage with dimensions of 0
3.89 KB, patch
mattwoodrow
: review+
Details | Diff | Splinter Review
Test for bug 813372, v1.1
2.39 KB, patch
mattwoodrow
: review+
Details | Diff | Splinter Review
Fix rebased on beta
3.89 KB, patch
Details | Diff | Splinter Review 
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
blocking-basecamp: ? → +
+cc: jwatt

Can you trap the crash on your B2G phone?
Assignee: nobody → jwatt
blocking-basecamp: + → ?
blocking-basecamp: ? → +
(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.
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
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.
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)
Attached 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: 8 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.