Closed Bug 816879 Opened 7 years ago Closed 7 years ago

3rd party app Bubble Meadow freezes after first move in game

Categories

(Firefox for Android :: General, defect)

19 Branch
ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 21

People

(Reporter: adora, Assigned: kats)

References

Details

Attachments

(3 files)

Steps to duplicate:
1.  Install and launch game:  http://www.logicking.com/games/BubbleMeadow/bubbleMeadow.webapp
2.  Start the first level
3.  Tap to throw the ball

Observe:  Character freezes, after a few seconds an error message appears that says "Aurora isn't responding.  Do you want to close it?"  Screenshot:  http://adora.io/screens/bubble_meadow_not_responding-20121130-003001.png

Expected result:  Character should reach for another ball, which will be thrown again after tapping.

Error cannot be duplicated on desktop or Firefox OS.
I ran this on my Galaxy Nexus (Android 4.1.2) with Nightly (11/03) and got the same result. My guess is that the application is stuck in infinite loop on something; Gecko starts trimming memory until Android just closes Fennec.

D/GeckoMemoryMonitor( 4925): onTrimMemory() notification received with level 15
Can you retest with the patch on bug 803154? That should resolve this bug at least, even though it doesn't solve the general problem of bug 803149.
Keywords: qawanted
Running 01/30 Nightly, it still seems to be an issue with the steps in comment #0 with an eventual kill of Fennec after a minute; D/GeckoMemoryMonitor( 3037): onTrimMemory() notification received with level 15
Keywords: qawanted
Doh. level 15 corresponds to ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL which we treat as a "high" level of memory pressure, so this still blocks. Looking at the levels in ComponentCallbacks2 again I think our mapping to memory pressure levels is not right. I will put up a patch.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> Doh. level 15 corresponds to
> ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL which we treat as a "high"
> level of memory pressure, so this still blocks. Looking at the levels in
> ComponentCallbacks2 again I think our mapping to memory pressure levels is
> not right. I will put up a patch.

While you might be right that our levels are wrong, we might also want to be able to take action on a HIGH event without blocking. AFAIK, we only really need this in response to onLowMemory, so maybe we should just move the geckoEventSync() call there and remove it from MemoryMonitor entirely.
Attachment #708212 - Attachment description: Map all foreground memory pressure events to "low" → Part 1 - Map all foreground memory pressure events to "low"
Attachment #708219 - Flags: review?(snorp) → review+
Attachment #708212 - Flags: review?(snorp) → review+
https://hg.mozilla.org/mozilla-central/rev/2f0cf6930eec
https://hg.mozilla.org/mozilla-central/rev/2d6e2f861e19
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
You need to log in before you can comment on or make changes to this bug.