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

VERIFIED FIXED in Firefox 21

Status

Firefox OS
Gaia
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: cjones, Assigned: gsvelto)

Tracking

({regression})

unspecified
B2G C4 (2jan on)
x86_64
Linux
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

Details

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.
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.
blocking-b2g: tef? → tef+
Assignee: nobody → 21
Chris is it a duplicate of bug 836654 ? Or a more specific version?
Flags: needinfo?(jones.chris.g)
This is a symptom of a problem that bug 836654 should fix.
Depends on: 836654
Flags: needinfo?(jones.chris.g)
(Assignee)

Comment 5

5 years ago
Takin' this. I'll try to reproduce it with the patches from bug 836654 applied to see if it gets fixed for good.
Assignee: 21 → gsvelto
Status: NEW → ASSIGNED
Don't forget the Gaia patch and also the bugs which block bug 836654.
(Assignee)

Comment 7

5 years ago
(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.
> How hard would it be to backport your fix and its dependencies to mozilla-b2g18?

I just pushed.  :)
(Assignee)

Comment 9

5 years ago
(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?).
(Assignee)

Comment 10

5 years ago
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.
(Assignee)

Comment 11

5 years ago
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
Right; I just pushed a fix (there are a few more compile errors after that).
(Assignee)

Comment 13

5 years ago
(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?
> 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.
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → fixed
status-firefox19: --- → wontfix
status-firefox20: --- → wontfix
status-firefox21: --- → fixed
Target Milestone: --- → B2G C4 (2jan on)

Comment 16

5 years ago
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
Status: RESOLVED → VERIFIED

Updated

5 years ago
status-b2g18-v1.0.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.