Closed Bug 986753 Opened 7 years ago Closed 7 years ago
[Tarako] Alarm Clock can get killed in the background and never ring
1. launch alarm clock 2. set alarm for 2 minutes into the future with a ring 3. launch camera 4. take a picture 5. switch to gallery 6. open the picture 7. edit the picture, crop, sepia, effects 8. save the picture 9. repeat 6 to 8 until past the time Expected: the alarm rings on time Actual: the alarm doesn't ring Gaia 63a7f183788218871c95a887328d091d58519edf Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/818e38fe5f4d BuildID 20140321101803 Version 28.0 ro.build.version.incremental=86 ro.build.date=Thu Mar 20 11:25:47 CST 2014 Tarako Note: 1. sometimes after you reboot the alarm might go off with the time that you had set it to.
noming because the purpose of the alarm fails to function.
traige: 1.3T+ for failing functinoality ni? Dylan, do you mind having someone to look at it? Thanks
blocking-b2g: 1.3T? → 1.3T+
cc: bkelly Marcus, can you work with Ben on this one to learn some of the perf team's tricks of the trade on handling Tarako low memory situations?
Assignee: nobody → m
I can ping :bkelly, though this particular bug looks more like a clock alarm-firing bug than anything else (unless Clock is somehow getting killed when it's trying to fire the alarm, though that seems unlikely). Will look into it.
Status: NEW → ASSIGNED
Yea, I'd say figuring out if the alarm is trying to fire or not would be the first step. Do we use a hardware clock or something to get notified about the alarm? I wonder if the firmware bits are there or not. Please let me know if I can help with any general memory or perf investigation questions.
In the voice of Monk, here's what happened: In super-high-memory-pressure situations, it may take a long time for the pressure to be relieved enough for Clock's alarm screen to boot up (load modules, etc). The module loader was set to timeout after 7 seconds; if it took longer than that to load the modules, the loader would timeout and the alarm would never display. In manual testing, upping the timeout value caused the alarm to properly fire when the phone caught up with memory use. In this patch, I set the limit at 3 minutes -- but it really could be arbitrarily high. I'm having :jrburke review this, in case he has any thoughts on setting an even higher value.
Comment on attachment 8396458 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17587 I added some info to the pull request, feel free to comment or update the pull request an flip it back to me for review.
Comment on attachment 8396458 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17587 Yes, your suggestion is much better. I've revised it accordingly and verified that waitSeconds actually does get set to 0 in the app zip after `make`.
Attachment #8396458 - Flags: review?(jrburke) → review+
Comment on attachment 8396458 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17587 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): n/a [User impact] if declined: Alarms may fail to fire if the phone is under severe memory pressure at alarm time. [Testing completed]: Verification on Tarako. [Risk to taking this patch] (and alternatives if risky): Low risk. [String changes made]: None.
Attachment #8396458 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
Hi, sorry had to revert this change since i think this might have caused test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=36703800&tree=B2g-Inbound
It seems highly unlikely that this is the cause of those failures. Did backing it out solve the TBPL failures you saw, Carsten?
yeah the failures cleared up after i backed this out, which might also be not really depend on this backout but on the other reverts and issues like bug 971585 we had. I guess if its unlikey that this one caused the test failure you could land this again :)
Thanks for the quick reply, Carsten. Since Travis was happy and this ought to have nothing to do with the failures you saw, I relanded. If you see further problems, of course, let me know. master: 65c1f1385a00a897a62f35886bb03ec350b3b79c
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
verified and fixed with v1.3t Gaia 98ce1340a6c27694f3b32a36b772e8da57caf19a Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/bdf9a55b4553 BuildID 20140409164001 Version 28.1
You need to log in before you can comment on or make changes to this bug.