840257 - Dialer not launched on incoming call when under memory pressure (failing MW4)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

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

STR
 (1) Run the steps at https://wiki.mozilla.org/index.php?title=B2G/Memory_acceptance_criteria#MW4:_Apps_are_successfully_launched_into_the_foreground_under_memory_pressure

The incoming call is dropped by b2g because the dialer isn't launched.

Needs to block.

Comment 1

[Gregor Wagner [:gwagner]]

I also noticed a behavior where we go into super slow mode if we are low on memory and the call shows up 30sec after I dropped it from the other phone.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Blocking for now based on current understanding of acceptance criteria.  We will review this tomorrow in a partner triage session to confirm if it will remain blocking.

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Chris is it a duplicate of bug 836654 ? Or a more specific version?

Comment 4

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

This is a symptom of a problem that bug 836654 should fix.

Comment 5

[Gabriele Svelto [:gsvelto] (PTO)]

Takin' this. I'll try to reproduce it with the patches from bug 836654 applied to see if it gets fixed for good.

Comment 6

[Justin Lebar (not reading bugmail)]

Don't forget the Gaia patch and also the bugs which block bug 836654.

Comment 7

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Justin Lebar [:jlebar] from comment #6)
> Don't forget the Gaia patch and also the bugs which block bug 836654.

I reproduced the issue on mozilla-b2g then tried out the latest central which has your patches for bug 836654 with the gaia part too. With your patches the problem's fixed and I can see the call showing up immediately while reproducing the steps that cause the issue.

How hard would it be to backport your fix and its dependencies to mozilla-b2g18? I've tried applying the patches there and succeeded with some manual adjustments but I haven't tried compiling yet.

Comment 8

[Justin Lebar (not reading bugmail)]

> How hard would it be to backport your fix and its dependencies to mozilla-b2g18?

I just pushed.  :)

Comment 9

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Justin Lebar [:jlebar] from comment #8)
> I just pushed.  :)

Great! \o/

I'll re-test on b2g18 and if the problem's fixed I think we can safely close this (as a duplicate maybe?).

Comment 10

[Gabriele Svelto [:gsvelto] (PTO)]

I'm hitting this issue when trying to compile the latest mozilla-b2g18:

/home/gsvelto/projects/mozilla-b2g18/hal/HalWakeLock.cpp: In function 'void mozilla::hal_impl::GetWakeLockInfo(const nsAString_internal&, mozilla::hal::WakeLockInformation*)':
/home/gsvelto/projects/mozilla-b2g18/hal/HalWakeLock.cpp:265: error: no match for 'operator=' in 'aWakeLockInfo->mozilla::hal::WakeLockInformation::lockingProcesses() = totalCount.mozilla::hal_impl::<unnamed>::LockCount::processes'
../dist/include/nsTArray.h:1289: note: candidates are: InfallibleTArray<long long unsigned int>& InfallibleTArray<long long unsigned int>::operator=(const InfallibleTArray<long long unsigned int>&)
make: *** [HalWakeLock.o] Error 1

I've clobbered the objdir-gecko directory but to no avail.

Comment 11

[Gabriele Svelto [:gsvelto] (PTO)]

Since the two types are an InfallibleTArray<> and a regular nsTArray<> I think it's because we're missing this change from central on b2g18:

https://hg.mozilla.org/mozilla-central/rev/1a0cd3aa1864

Comment 12

[Justin Lebar (not reading bugmail)]

Right; I just pushed a fix (there are a few more compile errors after that).

Comment 13

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Justin Lebar [:jlebar] from comment #12)
> Right; I just pushed a fix (there are a few more compile errors after that).

I just re-run the test with the last fix you pushed and everything's working fine. I can run the "Bust processes" operation and still receive calls afterwards. Should this be verified by QA before we close?

Comment 14

[Justin Lebar (not reading bugmail)]

> Should this be verified by QA before we close?

QA can come back and move from resolved to verified if they want, but I'm happy with your testing, myself.

Comment 15

[Gabriele Svelto [:gsvelto] (PTO)]

OK, for reference this are the commits that fixed the issue:

http://hg.mozilla.org/releases/mozilla-b2g18/rev/3de3a83f5bf2
http://hg.mozilla.org/releases/mozilla-b2g18/rev/a2396ec10915
http://hg.mozilla.org/releases/mozilla-b2g18/rev/946bda7e750a
http://hg.mozilla.org/releases/mozilla-b2g18/rev/17e04bbdcf5b
http://hg.mozilla.org/releases/mozilla-b2g18/rev/971705534b1e
http://hg.mozilla.org/releases/mozilla-b2g18/rev/1799c434ac71
http://hg.mozilla.org/releases/mozilla-b2g18/rev/66c893cf5c10
http://hg.mozilla.org/releases/mozilla-b2g18/rev/95baa4ffc85d
http://hg.mozilla.org/releases/mozilla-b2g18/rev/d2c83ced1c9d
http://hg.mozilla.org/releases/mozilla-b2g18/rev/e874d5ba8354
http://hg.mozilla.org/releases/mozilla-b2g18/rev/905002d0ddd1
http://hg.mozilla.org/releases/mozilla-b2g18/rev/6cfeb6a43942

Comment 16

[Natalya Kot [:nkot]]

Verifying fix - issue does not reproduce anymore

- The dialer is launched successfully, incoming call is not dropped by unagi after busting system memory
(link http://people.mozilla.org/~jgriffin/membuster.html was used for testing)

tested with the following builds:
V1.1.0
Build ID 2013-03-28-0702024
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/dc653b5b2339
Gaia   6dbf0b68622aa80d079fee2af660ddc47f7cd7df

V1.0.1
Build ID 2013-03-28-070202
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/c516d7e67150
Gaia   d40dcdd112f12e2a5a0d1de46451670918fd4369