Closed Bug 798035 Opened 7 years ago Closed 7 years ago

[b2g-bluetooth] Bluetooth Manager classes double-inherit refcounting semantics, crash

Categories

(Core :: DOM: Device Interfaces, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: qdot, Assigned: qdot)

References

Details

Attachments

(2 files)

Due to BluetoothHfp/ScoManager inheriting from both nsISupports and RefCounted<>, we get double releases when they die.
blocking-basecamp: --- → ?
Get() never worked in this configuration, and we have no need for an SCOCommandThread.
Attachment #668203 - Flags: review?(gyeh)
Comment on attachment 668203 [details] [diff] [review]
Patch 2 (v1) - General SCO class cleanup

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

::: dom/bluetooth/BluetoothScoManager.cpp
@@ -100,3 @@
>  BluetoothScoManager::Cleanup()
>  {
>    // Shut down the command thread if it still exists.

Also remove the comment here.
Attachment #668203 - Flags: review?(gyeh) → review+
Comment on attachment 668201 [details] [diff] [review]
Patch 1 (v1) - Make observers internal friend classes of managers

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

Looks good :)

::: dom/bluetooth/BluetoothScoManager.cpp
@@ +66,5 @@
> +                                     const PRUnichar* aData)
> +{
> +  if (!strcmp(aTopic, NS_XPCOM_SHUTDOWN_OBSERVER_ID)) {
> +    return gBluetoothScoManager->HandleShutdown();
> +  }

We probably need to check gBluetootScoManager before calling its function.

MOZ_ASSERT(gBluetoothScoManager);
Attachment #668201 - Flags: review?(gyeh) → review+
blocking-basecamp: ? → +
You need to log in before you can comment on or make changes to this bug.