Closed Bug 855717 Opened 12 years ago Closed 12 years ago

Intermittent B2G test_bug467672-4g.html,test_attrspecifiedvalueremove.html,test_location_setters.html,test_attrparentnodenull.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file layers/LayersSurfaces.h, line 83)

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

References

Details

(Keywords: assertion, crash, intermittent-failure)

Hooray for our fancy new logging code! Ben/Andrew, this is on b2g18, so does that move it up the priority totem pole? https://tbpl.mozilla.org/php/getParsedLog.php?id=21197399&tree=Mozilla-B2g18 b2g_ics_armv7a_gecko_emulator mozilla-b2g18 debug test mochitest-8 on 2013-03-28 01:42:06 PDT for push dc653b5b2339 slave: talos-r3-fed-005 02:07:32 INFO - [Child 974] ###!!! ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83 02:13:02 WARNING - TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug467672-4g.html | application timed out after 330 seconds with no output 02:16:13 ERROR - Return code: 1 02:16:15 ERROR - F/libc ( 928): Fatal signal 11 (SIGSEGV) at 0x47f00000 (code=2) 02:16:15 ERROR - This usually indicates the B2G process has crashed 02:16:15 INFO - I/Gecko ( 974): [Child 974] ###!!! ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83 02:16:15 INFO - E/Gecko ( 974): mozalloc_abort: [Child 974] ###!!! ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83 02:16:15 ERROR - F/libc ( 974): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) 02:16:15 ERROR - This usually indicates the B2G process has crashed
I don't know what's going on here. There are only two places on b2g where this could be happening (I think!): http://mxr.mozilla.org/mozilla-b2g18/search?string=get_MagicGrallocBufferHandle&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-b2g18 In each case it looks like the code is checking the type properly before calling get_MagicGrallocBufferHandle(), so that should be fine. Maybe this is evidence of some kind of corruption? We need stacks to know anything more probably. CC'ing a few gfx people but I don't know who really owns this code.
Component: IPC → Graphics: Layers
Summary: Intermittent B2G emulator test_bug467672-4g.html | application timed out after 330 seconds with no output (ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83) → Intermittent B2G emulator test_bug467672-4g.html,test_attrspecifiedvalueremove.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83)
Summary: Intermittent B2G emulator test_bug467672-4g.html,test_attrspecifiedvalueremove.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file ../../ipc/ipdl/_ipdlheaders/mozilla/layers/LayersSurfaces.h, line 83) → Intermittent B2G emulator test_bug467672-4g.html,test_attrspecifiedvalueremove.html,test_location_setters.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file layers/LayersSurfaces.h, line 83)
Summary: Intermittent B2G emulator test_bug467672-4g.html,test_attrspecifiedvalueremove.html,test_location_setters.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file layers/LayersSurfaces.h, line 83) → Intermittent B2G test_bug467672-4g.html,test_attrspecifiedvalueremove.html,test_location_setters.html,test_attrparentnodenull.html | application timed out (ABORT: unexpected type tag: '(mType) == (aType)', file layers/LayersSurfaces.h, line 83)
https://tbpl.mozilla.org/php/getParsedLog.php?id=21430632&tree=Mozilla-B2g18_v1_0_1 GFX people, does someone have cycles to look into this please?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6) > https://tbpl.mozilla.org/php/getParsedLog.php?id=21430632&tree=Mozilla- > B2g18_v1_0_1 > > GFX people, does someone have cycles to look into this please? Benoit and/or Jeff, could you take a quick look?
Flags: needinfo?(bjacob)
Flags: needinfo?(jmuizelaar)
(In reply to ben turner [:bent] from comment #1) > We need stacks to know anything more probably. CC'ing a few gfx people but I > don't know who really owns this code. That was an interesting exercise in git archaeology. This header file, LayersSurfaces.h, is generated from LayersSurfaces.ipdlh. History for that file is short, because it was renamed from PLayers.ipdlh in 966f3cd. Going to the previous revision shows that the relevant code was mostly written in this changeset: commit 34ba9ea0472797eef4792757e3e273b60c601823 Author: Chris Jones <jones.chris.g@gmail.com> Date: Thu Jul 12 05:51:58 2012 -0700 Bug 765734, part 6: Integrate gralloc buffers into the shadow-layers pipelines. r=gal So to answer your question, this code was written by Chris Jones and reviewed by Andreas Gal. That is quite representative of the problems the gfx team is having at the moment with maintaining b2g18 gfx code: we didn't write or review most of that code, and some important authors have left (not just Chris but also Cody). I'm saying this to set expectations: although it's very likely that this is a simple bug and the mismatched surface type is likely just between "gralloc" and "null" i.e. we have a null surface where we should have a real surface --- it's not trivial for any of us to delve into this code. So basically, I'm waiting for Milan to tell me "this is a big concern to B2G people, please work on it even if that's going to take a while" before I'd actually work on this. Meanwhile I believe that our time is better used working the the layers-refactoring branch where we've seen similar crashes in the past on B2G, and fixed them, and which is set to land on m-c real soon now.
Flags: needinfo?(bjacob)
Thanks Benoit. We need to get B2G in the graphics branch to the level where we can land bug 852734, and then let's talk about revisiting this.
Flags: needinfo?(jmuizelaar)
We're not even considering uplifting any of the layers refactoring into b2g18/b2g18_v1_0_1, are we?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #11) > We're not even considering uplifting any of the layers refactoring into > b2g18/b2g18_v1_0_1, are we? No. Way, way too high risk.
(In reply to Nick Cameron [:nrc] from comment #12) > (In reply to Ryan VanderMeulen [:RyanVM] from comment #11) > > We're not even considering uplifting any of the layers refactoring into > > b2g18/b2g18_v1_0_1, are we? > > No. Way, way too high risk. Right - it's really the equivalent of moving to 22, then uplifting this from 23 to 22. If the decision is made to move B2G to 22+, then we can discuss it.
I guess what I was trying to ask was whether this is going to get resources for a fix *on* the b2g18 branches after that work finishes or if we're just going to punt on fixing this on the b2g18 branches.
From the practical point of view, no I don't see this getting high enough to get resources to get resolved on b2g18.
Closing inactive keywords:intermittent-failure bugs where the TBPLbot has previously commented and the test isn't marked as disabled; filter on orange-cleanup-201401.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.