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.
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+
Chris is it a duplicate of bug 836654 ? Or a more specific version?
This is a symptom of a problem that bug 836654 should fix.
Depends on: 836654
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.
(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. :)
(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?).
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.
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).
(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.
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
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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)
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
You need to log in before you can comment on or make changes to this bug.