837927 - Failed to launch Calendar during MW0

Status: VERIFIED WORKSFORME

(Core :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Run https://wiki.mozilla.org/index.php?title=B2G/Memory_acceptance_criteria#MW0:_Every_app_is_successfully_launched_into_the_foreground

Step 14 failed to launch Calendar.

Needs to block.  jlebar, please feel free to dup this or set deps as you see fit.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

jlebar, we should also consider dropping the foreground timer for apps, if the work you're currently doing isn't going to be landing tomorrow or so.

Comment 2

[Justin Lebar (not reading bugmail)]

So this regressed recently?  That's a bummer...

There are two fg timers: When an app is started, it stays in the fg for 5s.  And when an app is sent into the background, it stays in the fg for 1s.

I presume you're thinking that decreasing the first one would help with this?  We can do that, but at the risk of regressing bug 834059, which I'll be the first to agree isn't working as well as I'd like.  But I'd be surprised if you were going so fast with the test as to cause the 5s timer to make a difference.

I would love, love, love to cancel the 5s timer once the app "legitimately" goes into the fg, and if we can get help on the Gaia side with that, it would be fantastic.  That's essentially bug 835563, blocked on its dep.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Blocking so we can meet memory acceptance criteria for shipping.

Comment 4

[Justin Lebar (not reading bugmail)]

I can't reproduce this (sorry; I tried a few times), but bug 839312 might help.

Comment 5

[Justin Lebar (not reading bugmail)]

I can seem to reproduce sporadic application loading failures, now.  I'm not sure what the deal is, though.

Comment 6

[Justin Lebar (not reading bugmail)]

Attachment: WIP v1, for testing

cjones, if you have a few minutes, I'd appreciate if you could test this patch to see if this is an improvement.  It seems to work much better for me, but I was never able to reliably reproduce this problem in the first place.

I also landed bug 838615 and bug 838616 on m-c today, and I pushed 838615 to b2g18.  They don't seem to make a big difference themselves, but perhaps they help in combination with this patch.

(If you can do anything to get bug 838616 approved for b2g18 more quickly and with a minimal amount of fuss, that would help a lot.  This stuff is hard enough as it is, but when everyone is using a different subset of my changes, the combinatorics makes me a sad panda.)

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(Would like to test this but can't run the steps due to bug 839256.)

Comment 8

[Justin Lebar (not reading bugmail)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> (Would like to test this but can't run the steps due to bug 839256.)

Okay.  Let's move this patch to bug 835795, which is actually what the change is, and then we can determine whether it fixes the problem.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

We're de-prioritzing blocking on memory issues that are not comms (or alarm) for now - so taking this off the blockers list. Still tracking, and would like to know from QA if this is still reproducing.

Comment 10

[Jason Smith [:jsmith]]

lgtm on 4/15 b2g18 build.