Closed Bug 916895 Opened 8 years ago Closed 8 years ago
.me][Wrapper]Opening wrapper once ceases touch responses
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
This is bad, but doesn't meet the criteria of a smoketest blocker.
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.
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
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 -------
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.
Component: General → Graphics
Product: Boot2Gecko → Core
Version: unspecified → Trunk
As written, this is a blocker. Sotaro, please send to a module owner if you're not the right assignee here.
Assignee: nobody → sotaro.ikeda.g
blocking-b2g: koi? → koi+
(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?
Assignee: sotaro.ikeda.g → milan
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?
(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.
(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?
George is looking at this.
Assignee: milan → gwright
Back to me for placeholder - look here for updates, probably coming from Vlad next.
Assignee: gwright → milan
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.
(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.
Assignee: milan → nobody
No longer blocks: GFXB2G1.2
Component: Graphics → Gaia::System
Product: Core → Boot2Gecko
Version: Trunk → unspecified
Fixed by backout in https://bugzilla.mozilla.org/show_bug.cgi?id=914317#c14.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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.
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.
attachment added with logcat of actual behavior
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Backed out in https://bugzilla.mozilla.org/show_bug.cgi?id=914317#c18.
Verified as fixed on: Device: Buri v1.2 Mozilla RIL BuildID: 20131017004001 Gaia: dbcc171eae6b4d9d168a48291d5ea54c7580561a Gecko: 7ca5d1e81d37 Version: 26.0a2
You need to log in before you can comment on or make changes to this bug.