B2G telephony: unknown (outgoing) call index is assumed to be incoming later

RESOLVED FIXED in mozilla12

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: philikon, Assigned: Ben Turner (not reading bugmail, use the needinfo flag!))

Tracking

Trunk
mozilla12
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Regression introduced in bug 674726: an outgoing call somehow registers as an "incoming" one. Unsurprisingly, the following assertion is logged:

###!!! ASSERTION: Serious logic problem here!: 'aCallState == nsITelephone::CALL_STATE_INCOMING', file /home/philipp/dev/mc.hg/dom/telephony/Telephony.cpp, line 380

Subsequent events don't make it to the DOM either and often eventually lead to a crash. On the device it doesn't crash, but the DOM events seem to be AWOL as well and audio isn't turned on always (especially for incoming calls.)

I wouldn't be surprised if there were several bugs here, but for now I don't have any specific leads. I will start by reading the ril_worker.js and nsTelephoneWorker.js changes in bug 674726 very carefully again. There also seems to be something finish in the C++ side, particularly if you consider the crash in bug 717156.
Group: mozilla-corporation-confidential
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Hm, I goofed the outgoing index code somehow. Patch in a sec.
Created attachment 587723 [details] [diff] [review]
Patch, v1

I think this should do it. I wasn't handling that weird case where we don't yet know the RIL's callIndex yet properly.
Assignee: nobody → bent.mozilla
Status: NEW → ASSIGNED
Attachment #587723 - Flags: review?(mounir)
Summary: B2G telephony: call state is all sorts of messed up → B2G telephony: unknown (outgoing) call index is assumed to be incoming later
Created attachment 587806 [details] [diff] [review]
Patch, v2

bent and I found an additional problem that the v1 patch did not address.
Attachment #587723 - Attachment is obsolete: true
Attachment #587723 - Flags: review?(mounir)
Attachment #587806 - Flags: review?(mounir)
Comment on attachment 587806 [details] [diff] [review]
Patch, v2

>diff --git a/dom/telephony/Telephony.cpp b/dom/telephony/Telephony.cpp

>+        tempCall->CallState() < nsITelephone::CALL_STATE_CONNECTED) {

I prefer using bitfields and bitmasks to express sets of states,
but that can be fixed in a followup.  DISCONNECTED is > CONNECTED
so this is OK.

>+    if (tempCall->CallIndex() == PR_UINT32_MAX) {

Make a symbolic constant for this like
CALL_INDEX_OUTGOING_PLACEHOLDER (or something like that).  Make
sure to update the other places it's used.

>+  // If nothing matched above and the call state isn't incoming but we do have
>+  // an outgoing call then we must be seeing a status update for out outgoing
>+  // call.
>+  if (!modifiedCall &&
>+      aCallState != nsITelephone::CALL_STATE_INCOMING &&
>+      outgoingCall) {

This is pretty subtle but it looks right to me.  The problem is a
race condition between Gecko placing a call and ril receiving
one.

>diff --git a/dom/telephony/TelephonyCall.cpp b/dom/telephony/TelephonyCall.cpp

>+  if (aCallState == nsITelephone::CALL_STATE_DIALING) {
>+    mOutgoing = true;
>+  }
>+

Nit: |mOutgoing = (aCallState == nsITelephone::CALL_STATE_DIALING);|

pinch-r=me with those fixes.  I think this is pretty small but
let's ask Mounir if he wants a follow-on review.
Attachment #587806 - Flags: review?(mounir) → review+
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> Nit: |mOutgoing = (aCallState == nsITelephone::CALL_STATE_DIALING);|

This code gets run several times so I don't want to unset that. Thanks for the review!

https://hg.mozilla.org/integration/mozilla-inbound/rev/a9eb2cfdebd8
https://hg.mozilla.org/mozilla-central/rev/a9eb2cfdebd8
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Sorry for not getting to this review faster, I was at a career fair yesterday and didn't find time for this.
You need to log in before you can comment on or make changes to this bug.