This has bee reproduced on Ikura QC RIL version: "ro.build.firmware_revision=01.01.00.019.215" gaia commit: 4584c40 rm long short gecko commit: 8ae9e11 tengfei add eng code with 87274 SUMMARY Sometimes, when receiving a call while browsing, DuT alerts ringing but the incoming call screen is not shown, and as a consequence, it is not possible to accept or reject that call. STEPS TO REPRODUCE 1. Open browser (tested with URL www.at4wireless.com) 2. "Stress" the DUT by pressing some links 3. Receive an incoming call while browsing CURRENT RESULT The ringtone alerts the user about a new incoming call, but the incoming-call-screen is not shown so the user can't either pick it up or reject it. EXPECTED RESULT The user should see the incoming call screen so that s/he can decide what to do with it. ADDITIONAL INFO - This bug is not easy to reproduce and seems to be related to memory management, as it is easier to reproduce it when you have several applications running at the same time. - Anyway, this has been reported as a cert. blocker by the operator, so I will nominated it as leo? to triage it - Attached you will find a logcat

It sounds similar as bug 847592

Sounds like a memory pressure issue.

moving to 1.2

Can someone briefly explain to me why we believe this is a memory issue?

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #4) > Can someone briefly explain to me why we believe this is a memory issue? Probably because this bug seemed related to what we saw in bug 847592. In that bug, there was discussion indicating that the phone was running out of memory, resulting in the kernel killing the comms apps after the telephony-new-call message is sent and before the comms app launches. I might not be right here though. bug 847592 talks a lot about process priority management when we run out of memory. Perhaps this is just better tracked as just a general IPC issue. Let me know what you think.

Ok, that sounds reasonable. Let me see if I can find someone to work on this.

Kyle, found anyone to work on this issue? Thanks, FxOS Perf Triage

wchen is going to try to reproduce this.

Stealing from wchen! I'll have some results by tomorrow.

I tried to reproduce this bug, opening multiple tabs and also running the "membuster" application at the same time as I browsed the site given in comment 0. I couldn't reproduce the bug described here, though: the phone started ringing and the phone application opened without fail every time. I'll try again tomorrow with more apps open, but there might also be other factors here: in particular, I noticed in the log attached that its using the QC RIL, which could affect things. If QA could provide more information, that would be really useful, though, in particular, the dmesg output when this bug reproduces to see if the kernel is, in fact, killing the communications application. I was also wondering if the browser was strictly necessary (which could be the case as it lives in the parent process) or if it was possible to reproduce this bug with a combination (e.g.) of the membuster app and maybe crystal skull. In other words, trying to peg the CPU artificially and use up as much memory as possible.

Note for qawanted - we should try testing this on a mozilla ril 1.2 build & comm ril 1.2 build

Attempted to repro on Buri 1.2 10/03/13 & 10/25/13 builds with COM and MOZ ril, but I could NOT reproduce the bug. I opened many tabs in the browser and played a YouTube video while a call was incoming. The 10/03 build seemed to take longer to start ringing and show the call menu, but it did show up. Environmental Variables: Device: Buri v1.2 comRIL & mozRIL BuildID: 20131003004003 Gaia: 9e21b6bea92fdafcb6787120a8cde0eb25a50495 Gecko: 7dfe4a775531 Version: 26.0a2 RIL version: 01.02.00.019.064 Environmental Variables: Device: Buri v1.2 comRIL & mozRIL BuildID: 20131025004000 Gaia: 606517ceafe0950c2b89822d5f13353743334f2c Gecko: 5eabd267ef04 Version: 26.0a2 RIL Version: 01.02.00.019.082

(In reply to Matthew Vaughan from comment #12) > Attempted to repro on Buri 1.2 10/03/13 & 10/25/13 builds with COM and MOZ > ril, but I could NOT reproduce the bug. I opened many tabs in the browser > and played a YouTube video while a call was incoming. The 10/03 build seemed > to take longer to start ringing and show the call menu, but it did show up. Hi Matthew, Could you please share how many times you have tried to reprduce this issue? The bug was only reproduced only sometimes and in a Ikura V1.1 scenario, so the reproducibility may be more difficult on the scenario you are currently testing. I wouldn't like to discard this bug yet until we are sure that, at least, the frequency to reproduce this is low enough for all of us to feel confortable with it. Thanks

(In reply to Juan Perez-Bedmar [:juanpbf] @Madrid from comment #13) > (In reply to Matthew Vaughan from comment #12) > > Attempted to repro on Buri 1.2 10/03/13 & 10/25/13 builds with COM and MOZ > > ril, but I could NOT reproduce the bug. I opened many tabs in the browser > > and played a YouTube video while a call was incoming. The 10/03 build seemed > > to take longer to start ringing and show the call menu, but it did show up. > > Hi Matthew, > > Could you please share how many times you have tried to reprduce this issue? > The bug was only reproduced only sometimes and in a Ikura V1.1 scenario, so > the reproducibility may be more difficult on the scenario you are currently > testing. > I wouldn't like to discard this bug yet until we are sure that, at least, > the frequency to reproduce this is low enough for all of us to feel > confortable with it. > > Thanks FWIW - If the STR is tougher to reproduce, it might be worth getting a video of the bug when it reproduces. That will help make this bug more actionable.

I attempted to repro this bug about 20 times. This testing was split between Buri 1.2 10/03/13 & 10/25/13 builds with COM and MOZ ril... so about 4-5 times per area. At times it seemed like it was about to repro, but the call screen would always appear eventually (meaning it could take about 2-3 rings from the caller's end before the call screen and ringer would trigger on the Buri).

Can't block on this if it's not possible to action.

Matt, can you run a couple more tests and look in the logcat to see when the phone is getting the call from the network? I think RIL should show something when the call comes in. We're wondering how much of the delay is coming from the network vs. just showing the screen. I also updated the subject line since a slow-to-show call screen is also a problem.

Minusing, as it's unclear that the problem is something we can control. Please renominate if it's clear the delay is on the receiving end.

I tested further on the 10/30/13 1.2 build with mozRIL. I was able to get a little bit of a delay on the test phone (about 2 rings) on a few phone calls, but most came through in about one ring. However there were a few times that I would try to call, and the ringer & call screen would not trigger on the test phone. This would occur about once every 8 call attempts when I have about 5 tabs open (one of those tabs with a heavy resource using page such as a YouTube video) in the active Browser. If I tried to call right after this happened then it would take about 2 rings before the ringer & call screen triggered on the test phone. I have attached LogCat_10-30-13 that was captured using the 10/30/2013 1.2 mozRIL build where the ringer & call screen did not trigger. There were 6 tabs open in the Browser with the Dialer app active in the background. In the active tab on the Browser, a YouTube video was being started (and phone rotated for full screen) while a call to the test phone was being made. Environmental Variables: Device: Buri v1.2 mozRIL BuildID: 20131003004003 Gaia: 9e21b6bea92fdafcb6787120a8cde0eb25a50495 Gecko: 7dfe4a775531 Version: 26.0a2

Hi Matthew, (In reply to Matthew Vaughan from comment #19) > I tested further on the 10/30/13 1.2 build with mozRIL. I was able to get a > little bit of a delay on the test phone (about 2 rings) on a few phone > calls, but most came through in about one ring. Thanks for retesting this. Have you been able to test/reproduce this with COMril? > > However there were a few times that I would try to call, and the ringer & > call screen would not trigger on the test phone. This would occur about once > every 8 call attempts when I have about 5 tabs open (one of those tabs with > a heavy resource using page such as a YouTube video) in the active Browser. > If I tried to call right after this happened then it would take about 2 > rings before the ringer & call screen triggered on the test phone. Once each 8 calls seems a quite high rate. This is likely to be a cert blocker if reproduced in commercial devices. That's why I think it's important to check this with COMril. > I have attached LogCat_10-30-13 that was captured using the 10/30/2013 1.2 > mozRIL build where the ringer & call screen did not trigger. There were 6 > tabs open in the Browser with the Dialer app active in the background. In > the active tab on the Browser, a YouTube video was being started (and phone > rotated for full screen) while a call to the test phone was being made. Can we know checking the logs if it's caused by RIL issue or upper level? Thanks!!! David

Resolved per whiteboard