Closed
Bug 717158
Opened 13 years ago
Closed 13 years ago
B2G telephony: unknown (outgoing) call index is assumed to be incoming later
Categories
(Core :: DOM: Device Interfaces, defect)
Core
DOM: Device Interfaces
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: philikon, Assigned: bent.mozilla)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•13 years ago
|
Group: mozilla-corporation-confidential
Updated•13 years ago
|
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
Assignee | ||
Comment 1•13 years ago
|
||
Hm, I goofed the outgoing index code somehow. Patch in a sec.
Assignee | ||
Comment 2•13 years ago
|
||
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 | ||
Updated•13 years ago
|
Summary: B2G telephony: call state is all sorts of messed up → B2G telephony: unknown (outgoing) call index is assumed to be incoming later
Reporter | ||
Comment 3•13 years ago
|
||
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+
Assignee | ||
Comment 5•13 years ago
|
||
(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
Comment 6•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Comment 7•13 years ago
|
||
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.
Description
•