916895 - [B2G][Everything.me][Wrapper]Opening wrapper once ceases touch responses

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[gbennett]

Attachment: WrapperEverythingMElog.txt

Description:
After opening the wrapper the entire app becomes unresponsive along with trying to open the wrapper again.

Repro Steps:
1) Updated Buri 1.2 mozRIL to Build ID: 20130916040205
2) Open everything.me
3) Go to games > CrayFrog
4) Open up the wrapper and let it close.
5) Try opening up the wrapper or using the app.

Actual:
Wrapper and app do not repsond to touch.

Expected:
Wrapper and the entire app works properly and responds to touch.

Environmental Variables
Device: Buri 1.2 mozRIL
Build ID: 20130916040205
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1

Notes: This has occurred for all apps we have tried. ~8 apps.
Repro frequency: 100%, 10/10
Test Suite Name: Firefox OS Daily Smoketest
Link to failed test case:
See attached: http://www.youtube.com/watch?v=mnYTHdyZJ1g, WrapperEverythingMElog.txt

Comment 1

[Jason Smith [:jsmith]]

This is bad, but doesn't meet the criteria of a smoketest blocker.

Comment 2

[J Zimbrick]

This issue prevents the user from being able to add an everything.me favorite to the homescreen.  Opening the wrapper stops all e.me functonality, including the buttons on the wrapper.

This explicitly fails step 4 of https://moztrap.mozilla.org/manage/cases/?filter-id=5856 , which is a smoketest case.

Comment 3

[Natalya Kot [:nkot]]

Regression range:
Build ID: 20130915040205 - Does NOT Reproduce
Gecko: http://hg.mozilla.org/mozilla-central/rev/9366ee039645
Gaia: 3f51f302c3a0c57d8bad482ec7ee86b2819389fb
Platform Version: 26.0a1

Build ID: 20130916040205 - Reproduces
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1

Comment 4

[Sotaro Ikeda [:sotaro]]

I found following log. It say canvas rendering update is aborted because of out of pmem. "regression from last night 9/15-9/16" say nothing about this regression, because from Sep/13-Sep/16, tiled rendering is enabled. It does not use pmem for ThebesLayer and it seems to prevent out of pmem.

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/CanvasClient.cpp#198

09-16 10:47:31.700: E/memalloc(140): /dev/pmem: No more pmem available
09-16 10:47:31.700: E/msm7627a.gralloc(140): gralloc failed err=Out of memory
09-16 10:47:31.700: W/GraphicBufferAllocator(140): alloc(640, 832, 1, 00000300, ...) failed -12 (Out of memory)
09-16 10:47:31.730: D/HWComposer(140): Frame rendered
09-16 10:47:31.880: I/Gecko(1952): Unexpected non-Gralloc SharedSurface in IPC path!
09-16 10:47:31.900: I/Gecko(1952): SharedSurface_Gralloc::Create -------

Comment 5

[Sotaro Ikeda [:sotaro]]

tiled layer is enabld by Bug 887819. And it is disabled by Bug 916112.

Comment 6

[Sotaro Ikeda [:sotaro]]

Until August 28, a gralloc allocation policy is different from partner's one. It is changed in Bug 905784. Until the change only MozBuild ROM implicitly fallback gralloc buffer allocation from pmem to system memory. Bug 905784 banned the implicit fallback. Then the current way of gralloc allocation is as same as partnber's one.

Comment 7

[Alex Keybl [:akeybl]]

As written, this is a blocker. Sotaro, please send to a module owner if you're not the right assignee here.

Comment 8

[Sotaro Ikeda [:sotaro]]

(In reply to Alex Keybl [:akeybl] from comment #7)
> As written, this is a blocker. Sotaro, please send to a module owner if
> you're not the right assignee here.

Milan, can you find the correct assignee?

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

I will look for the assignee; in the meantime, it sounds like the fix to bug 905784 caused this blocker - should it be backed out while we're looking for a forward fix?

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to Milan Sreckovic [:milan] from comment #9)
> I will look for the assignee; in the meantime, it sounds like the fix to bug
> 905784 caused this blocker - should it be backed out while we're looking for
> a forward fix?

We can not choose this, this setting is just for MozBuild. Partner uses the setting in Bug 905784 since long time ago. If this setting is different, we can not reproduce the bug that partner is facing.

Comment 11

[Tony Chung [:tchung]]

(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> (In reply to Milan Sreckovic [:milan] from comment #9)
> > I will look for the assignee; in the meantime, it sounds like the fix to bug
> > 905784 caused this blocker - should it be backed out while we're looking for
> > a forward fix?
> 
> We can not choose this, this setting is just for MozBuild. Partner uses the
> setting in Bug 905784 since long time ago. If this setting is different, we
> can not reproduce the bug that partner is facing.

can you explain what you cannot reproduce?   the build that this was found on is from our mozilla nightly builds, that live at: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-hamachi/2013/09/2013-09-16-04-02-05/.  regression range is in comment 3.  why would it have broken overnight?

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

George is looking at this.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Back to me for placeholder - look here for updates, probably coming from Vlad next.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This looks like it's being caused by bug 914317 -- I get an error in the console when I try to repeat the STR, which is to launch CrazyFrog, open up the bar at the bottom, and then mash on the favorite star a bunch.  I see a JS error in the system app js/modal_dialog.js line 207, about something that was null (I didn't save the exact error).  Backing out that patch in a local build fixes this problem.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #14)
> This looks like it's being caused by bug 914317 -- I get an error in the
> console when I try to repeat the STR, which is to launch CrazyFrog, open up
> the bar at the bottom, and then mash on the favorite star a bunch.  I see a
> JS error in the system app js/modal_dialog.js line 207, about something that
> was null (I didn't save the exact error).  Backing out that patch in a local
> build fixes this problem.

Okay. That confirms this isn't a GFX issue then.

Comment 16

[Jason Smith [:jsmith]]

Fixed by backout in https://bugzilla.mozilla.org/show_bug.cgi?id=914317#c14.

Comment 17

[Chris Kreinbring [:CKreinbring]]

Verified fixed on Buri 1.2 mozilla RIL.  Opening and closing everything.me apps does not cause the screen to become unresponsive.

Build ID: 20130917180029
Gecko: http://hg.mozilla.org/mozilla-central/rev/53a2011a01b2
Gaia: 678c1d23150b0b9b037de9b2122fcccd75bdb6f5
Platform Version: 27.0a1

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Meta comment -- this bug got attributed to graphics purely on the presence of lots of graphics-related spam (and some scary looking messages, I agree) in the logs.  However, the one error that was key to this issue didn't seem to have been noticed and didn't make it into the attached log.

The log only covers ~30 seconds during the middle of the app's runtime.  For app issues like this, the entire log from app startup to where the problem happens should be captured if possible.  If it's an intermittent thing, the the entire logcat output immediately after the problem is seen should be grabbed, not just a snippet.

Comment 19

[Montoya Clemmons (MClemmons)]

In response to Comment 18, attached is log covering entire log from app startup to where the problem happens. Reproduced actual result from Comment 0 every time (5/5) this morning 9-19-2013.

Comment 20

[Montoya Clemmons (MClemmons)]

Attachment: Facebook LogCat

attachment added with logcat of actual behavior

Comment 21

[Allen Maxwell]

Comment 17 was incidentally verified on Buri master/m-c build when it should have been on v1.2

The app and wrapper continue to be unresponsive, issue continues to occur on:
Buri v1.2 Mozilla RIL
Gaia   c932c482c6944fa32724ce7af9e5423c4c2bcccd
SourceStamp 2e560c5ce351
BuildID 20130919004001
Version 26.0a2

Refer to comment 20 for more logcat info as requested in comment 18

Comment 22

[Jason Smith [:jsmith]]

(In reply to Allen Maxwell from comment #21)
> Comment 17 was incidentally verified on Buri master/m-c build when it should
> have been on v1.2
> 
> The app and wrapper continue to be unresponsive, issue continues to occur on:
> Buri v1.2 Mozilla RIL
> Gaia   c932c482c6944fa32724ce7af9e5423c4c2bcccd
> SourceStamp 2e560c5ce351
> BuildID 20130919004001
> Version 26.0a2
> 
> Refer to comment 20 for more logcat info as requested in comment 18

No. This is because the regressing patch was only backed out on master, not 1.2 branch. So this is fixed on trunk - the regressing patch wasn't backed out on 1.2, that's all.

Comment 23

[Jason Smith [:jsmith]]

Backed out in https://bugzilla.mozilla.org/show_bug.cgi?id=914317#c18.

Comment 24

[Montoya Clemmons (MClemmons)]

Verified as fixed on:

Device: Buri v1.2 Mozilla RIL
BuildID: 20131017004001
Gaia: dbcc171eae6b4d9d168a48291d5ea54c7580561a
Gecko: 7ca5d1e81d37
Version: 26.0a2