Closed Bug 824895 Opened 7 years ago Closed 7 years ago

b2g crash via dbus_func_send_async

Categories

(Firefox OS Graveyard :: General, defect, P1, major)

ARM
Gonk (Firefox OS)

Tracking

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-basecamp +
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: m1, Assigned: echou)

References

Details

Attachments

(2 files)

Attached file minidump decoded
We've seen a reoccurring crash in the BT code during stability test.

Test Steps:
1. Receive MT calls and answer the call.
2. When call is in progress, do BT on\off via settings.
3. mini dumps are generated in the phone.

Please see decoded minidump.
I will just bb+ this one. Please minus it if someone thinks it should be bb-. 
Eric, could you help this case?
Flags: needinfo?(echou)
blocking-basecamp: ? → +
Hi Michael,

(In reply to Michael Vines [:m1] from comment #0)
> Created attachment 695922 [details]
> minidump decoded
> 
> We've seen a reoccurring crash in the BT code during stability test.
> 
> Test Steps:
> 1. Receive MT calls and answer the call.
> 2. When call is in progress, do BT on\off via settings.
> 3. mini dumps are generated in the phone.
> 
> Please see decoded minidump.

I've checked minidump. The crash was caused by passing a null pointer into dbus function. I'm still figuring out. Answering a call may not be a necessary step to let this occur.

If you don't mind, to make sure how this occurs, could you please provide logcat? I believe there must be some libdbus error messages displayed. Thanks in advance.

Eric
Flags: needinfo?(echou)
(logs sent directly to Eric out-of-band)
While the turning-off Bluetooth process is running on a non-main thread, if SetProperty() is called on main thread, it may crash. That's because |mConnection| may have been set to nullptr in StopInternal() on that turning-off BT thread but it has still been used as a parameter sent into dbus_func_send_async().

This patch could fix this problem temporarily, we will call IsReady() at the beginning of SetProperty() to ensure that mConnection is not null. However, I think that we should not let non-main thread set mConnection, especially reset it to a nullptr, or it may cause a race like this. Maybe we need a follow-up for this, but sending a simple patch for now should be o.k.
Assignee: nobody → echou
Attachment #696509 - Flags: review?(gyeh)
Comment on attachment 696509 [details] [diff] [review]
patch 1: v1: check if everything is ready in SetProperty()

Review of attachment 696509 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for finding the root cause. This patch should be worked and let's file a follow-up for this.
Attachment #696509 - Flags: review?(gyeh) → review+
https://hg.mozilla.org/mozilla-central/rev/d78815cb0440
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Duplicate of this bug: 826108
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.