Closed Bug 986753 Opened 10 years ago Closed 10 years ago

[Tarako] Alarm Clock can get killed in the background and never ring


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

1.4 S4 (28mar)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: nhirata, Assigned: mcav)


(Keywords: perf, Whiteboard: [p=3])


(1 file)

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
BuildID   20140321101803
Version   28.0 Mar 20 11:25:47 CST 2014

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+
Flags: needinfo?(doliver)
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
Flags: needinfo?(doliver)
Keywords: perf
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.
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.
Attachment #8396458 - Flags: review?(jrburke)
Target Milestone: --- → 1.4 S4 (28mar)
Comment on attachment 8396458 [details] [review]
Link to Github pull-request:

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.
Attachment #8396458 - Flags: review?(jrburke)
Comment on attachment 8396458 [details] [review]
Link to Github pull-request:

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)
Attachment #8396458 - Flags: review?(jrburke) → review+
Landed in master:
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8396458 [details] [review]
Link to Github pull-request:

[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.4?
Attachment #8396458 - Flags: approval-gaia-v1.3?(fabrice)
Attachment #8396458 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+

sorry had to revert this change since i think this might have caused test failures like
Resolution: FIXED → ---
It seems highly unlikely that this is the cause of those failures. Did backing it out solve the TBPL failures you saw, Carsten?
Flags: needinfo?(cbook)
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 :)
Flags: needinfo?(cbook)
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
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
blocking-b2g: 1.3T+ → 1.3+
Attachment #8396458 - Flags: approval-gaia-v1.4?
Whiteboard: [p=3]
verified and fixed with v1.3t
Gaia      98ce1340a6c27694f3b32a36b772e8da57caf19a
BuildID   20140409164001
Version   28.1
You need to log in before you can comment on or make changes to this bug.