866795 - Tests for "Android 4.0 debug" (on central/related branches)

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Justin Wood (:Callek)]

+++ This bug was initially created as a clone of Bug #818576 +++

We have "Android 2.2 debug" builds on tbpl, but no tests are run against them. Tests run against debug builds might provide better diagnostics for some of our on-going intermittent failures.

It looks like there is some history to this issue; see bug 693015.

----

See also 818576 which added them to cedar, the issue here is that there is more work needed on the harness issue before moving this out to production everywhere.

Comment 1

[Kelsey Gilbert [:jgilbert]]

I would like to stress how important running debug tests is. Currently, we have NO COVERAGE for ANY of our non-static assertions on Mobile, not to mention any extra `#ifdef DEBUG` checks we do.

It doesn't matter whether we get Android 2.2 or 4.0, but we NEED this coverage.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

I totally agree that this is likely to make meaningful differences on the code quality front.  Maybe a worthwhile question is "who in release engineering would need to spend resources on this?  And what's the appropriate way to get this on their radar?"

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Jeff Gilbert [:jgilbert] from comment #1)
> It doesn't matter whether we get Android 2.2 or 4.0, but we NEED this
> coverage.

(In reply to Dan Mosedale (:dmose) from comment #2)
> I totally agree that this is likely to make meaningful differences on the
> code quality front.  Maybe a worthwhile question is "who in release
> engineering would need to spend resources on this?  And what's the
> appropriate way to get this on their radar?"

Bumping severity.

Comment 4

[Geoff Brown [:gbrown]]

Let's discuss this at next week's mobile testing meeting: https://wiki.mozilla.org/Mobile/Testing.

Comment 5

[Phil Ringnalda (:philor)]

A fun way to persuade releng (really, ateam rather than releng, but either way) of the seriousness of your intent and your willingness to embrace them would be to fix the failures that have been continually present on Cedar since the day they were turned on there, at the end of April. Just because they are currently miserable to deal with and unsuitable for widespread viewing and forced compliance doesn't mean you can't fix them.

Sometime between now and that wonderful future for which you long, some developer will have to say "okay, test_streams_element_capture_createObjectURL.html hits  'ABORT: bad Shmem: file PImageBridgeParent.cpp, line 830' and kills the run, let me see why and figure out how to make it not do that." Why not now?

Comment 7

[Ed Morley [:emorley]]

To see the debug tests, use:
https://tbpl.mozilla.org/?tree=Cedar&showall=1&jobname=android.*debug

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

One of the main failures seem to be:

Assertion failure: isFloatReg(), at ion/MoveResolver.h

which I've spun out to bug 888578.

Comment 9

[Phil Ringnalda (:philor)]

That was just the fresh bustage from Friday; if you look back one push, or twenty, you can see the normal permaoranges.

Comment 10

[Phil Ringnalda (:philor)]

And now we're back to the normal permaoranges, so you can start working on them without having to go back a couple of pushes.

Comment 11

[Phil Ringnalda (:philor)]

Again, to reiterate, once more, in case it wasn't clear: they are running on Cedar, you can work on greening them up. That's not sufficient to get them running everywhere, but it is necessary to, and would be a show of good faith to persuade the people who need to do other work to run them everywhere that their work would not be a waste of time, the way all the releng work so far has been.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Phil, I think you've done a good job being clear, which is much appreciated.  My guess is that this bug is falling victim to conflicting priorities.  My guess is that blassey or mfinkle are the folks who are most likely to know who (if anyone) might be able to put this near the top of their priority list.  Sadly, I have other work that I need to focus on, despite being keenly aware of the importance here.  :-/

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

Naveed, I see two assertions that come up frequently. Perhaps if we can get these addressed we'll be closer to getting the debug tests greened up.

10-04 17:24:32.835 F/MOZ_Assert( 2193): Assertion failure: label->used(), at ../../../js/src/jit/arm/CodeGenerator-arm.cpp:215
 10-01 14:58:48.578 F/MOZ_Assert( 2186): Assertion failure: js::GetObjectClass(aGlobal)->flags & (1<<7) (Not a global object!), at ../../../dom/indexedDB/IndexedDatabaseManager.cpp:235

Comment 14

[Kelsey Gilbert [:jgilbert]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #13)
> Naveed, I see two assertions that come up frequently. Perhaps if we can get
> these addressed we'll be closer to getting the debug tests greened up.
> 
> 10-04 17:24:32.835 F/MOZ_Assert( 2193): Assertion failure: label->used(), at
> ../../../js/src/jit/arm/CodeGenerator-arm.cpp:215
>  10-01 14:58:48.578 F/MOZ_Assert( 2186): Assertion failure:
> js::GetObjectClass(aGlobal)->flags & (1<<7) (Not a global object!), at
> ../../../dom/indexedDB/IndexedDatabaseManager.cpp:235

The second one should have been fixed in bug 922837.

Comment 15

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #13)
> Naveed, I see two assertions that come up frequently. Perhaps if we can get
> these addressed we'll be closer to getting the debug tests greened up.
> 
> 10-04 17:24:32.835 F/MOZ_Assert( 2193): Assertion failure: label->used(), at
> ../../../js/src/jit/arm/CodeGenerator-arm.cpp:215
>  10-01 14:58:48.578 F/MOZ_Assert( 2186): Assertion failure:
> js::GetObjectClass(aGlobal)->flags & (1<<7) (Not a global object!), at
> ../../../dom/indexedDB/IndexedDatabaseManager.cpp:235

The first one was filed found by fuzzers and filed as bug 879647 (with a testcase) for quite some time now.

Comment 16

[Naveed Ihsanullah [:naveed]]

Assigned related bug https://bugzilla.mozilla.org/show_bug.cgi?id=879647 to Marty. He is looking into other bugs that throw this assertion right now so I expect we will know more soon.

Comment 17

[Phil Ringnalda (:philor)]

Here's one to get you started: test_videocontrols_audio_direction.html has 30 instances of "ASSERTION: Should be in construction phase: 'InConstruction()', file ../../../gfx/layers/basic/BasicLayerManager.cpp, line 581"

Comment 18

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Phil Ringnalda (:philor) from comment #17)
> Here's one to get you started: test_videocontrols_audio_direction.html has
> 30 instances of "ASSERTION: Should be in construction phase:
> 'InConstruction()', file ../../../gfx/layers/basic/BasicLayerManager.cpp,
> line 581"

philor, these assertions are the reason we want debug tests. Until we get them green enough to unhide though, no one is going to notice the failures. It seems like you are watching them though, so can you file bugs for the assertions you see? This layer manager assertion needs to be looked at by a completely different team (gfx) than the JS assertions I need-info'd naveed for.

Comment 19

[Phil Ringnalda (:philor)]

Well played.

Comment 20

[Geoff Brown [:gbrown]]

Android 4.0 is retired. We run a fairly full suite of debug tests on Android 4.3 emulators now.