"Communications has crashed" then re-dial of previous call

RESOLVED WORKSFORME

Status

()

Core
DOM: Device Interfaces
P3
normal
RESOLVED WORKSFORME
6 years ago
3 years ago

People

(Reporter: GH to BZ, Unassigned)

Tracking

({crash})

unspecified
crash
Points:
---

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Whiteboard: [label:dialer])

(Reporter)

Description

6 years ago
[GitHub issue by overholt on 2012-09-21T20:48:34Z, https://github.com/mozilla-b2g/gaia/issues/5043]
I'm not sure if this will ever be reproducible, but here's what happened:

- I made a phone call to person A (I think my cheek hit the hang-up button in the middle but other than that disconnect things were okay)
- I hung up
- I made a phone call to person B
- I hung up
- I looked at the phone and it said "Communications has crashed" along the bottom
- then I could hear person A saying "Hello?" even though it did not appear a call was in progress
- I couldn't hang up so person A hung up
- I tried to make a call to person C but it never completed

I reset the phone since I didn't know what would happen next :)
(Reporter)

Comment 1

6 years ago
[GitHub comment by etiennesegonzac on 2012-09-23T07:13:25Z]
Since the Dialer app is finally **really** OOP (wasn't when we still had the in process background service) it can be killed, leaving the RIL with an ongoing call.

I don't the details of the memory management strategy in gecko but if possible we should probably try to avoid killing an app with an attention screen open (ie. with *a* window active, but the main window hidden).

Ping @cgjones
Keywords: crash
Chris,

I don't know what is the exact process for killing an application but will it be possible to fire something on the application to let it know it will be killed? That will at least live a change to the communications app to stop the call.

Also is there a way from the front-end to adjust the oom_score?
Flags: needinfo?(jones.chris.g)
We never kill foreground apps.  Are you talking about closing apps through the task switcher?  Or maybe this was crash?

We know in the telephony DOM impl when a client has exited unexpectedly, so it's probably best to do cleanup there.
Flags: needinfo?(jones.chris.g)

Updated

6 years ago
Priority: -- → P3

Comment 4

6 years ago
What's there to do here? Is this reproducible?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #3)
> We never kill foreground apps.  Are you talking about closing apps through
> the task switcher?  Or maybe this was crash?

If the "Communications has crashed" banner showed up, that means that there was a fatal mozbrowsererror.

> We know in the telephony DOM impl when a client has exited unexpectedly, so
> it's probably best to do cleanup there.

If that's the case should this bug be moved over to a different component?
Keywords: qawanted
(In reply to Margaret Leibovic [:margaret] from comment #4)
> What's there to do here? Is this reproducible?
> 
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #3)
> > We never kill foreground apps.  Are you talking about closing apps through
> > the task switcher?  Or maybe this was crash?
> 
> If the "Communications has crashed" banner showed up, that means that there
> was a fatal mozbrowsererror.

For OOP content, that means a crash.

> 
> > We know in the telephony DOM impl when a client has exited unexpectedly, so
> > it's probably best to do cleanup there.
> 
> If that's the case should this bug be moved over to a different component?

Sure.  Core -> DOM:Device Interfaces should be fine.

Comment 6

6 years ago
Okay, I'll move this over.
Component: Gaia → DOM: Device Interfaces
Product: Boot2Gecko → Core

Comment 7

6 years ago
do you think you have a few minutes to look into this?
If we have an active call, then we should probably change the oom_adj/oom_score_adj in a manner that makes the Dialer less likely to be chosen.
Moving this to blocking-. We've only seen this problem once and that didn't result in enough actionable data.

If this is happening more often then surely we'll find it through dogfooding.
blocking-basecamp: + → -

Comment 10

6 years ago
Unable to repro this issue on Unagi

Build ID: 20130208070202
Kernel: Dec 5
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/4518b78583d0
Gaia   7e54ca673277b20b1d91d18477dc44d6ad226761
Looks like we tried to repro but couldn't in comment 10. Removing qawanted. If the problem reappears go ahead and re-add the flag.
Keywords: qawanted
Havne't seen this for over a year. Going to close it.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.