Closed Bug 798035 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: DOM: Device Interfaces, defect)

x86_64
Linux
defect
Not set
normal

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.

Attachment

General

Created:
Updated:
Size: