Closed Bug 791811 Opened 12 years ago Closed 12 years ago

[b2g-bluetooth] DeviceCreated signal asserts due to BluetoothService access on DBus Signal thread

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

(1 file, 2 obsolete files)

Bug 790133 asserts due to BluetoothService::Get being called off the main thread, since it tries to access BluetoothService from the EventFilter, which runs on the Bluetooth DBus Signal thread.
Assignee: nobody → kyle
Ok, so after calling BluetoothService::Get(), which starts with MOZ_ASSERT(NS_IsMainThread()), it's specifically calling GetDevicePropertiesInternal where the first line is MOZ_ASSERT(NS_IsMainThread()). Come on guys. Test your code in Debug please.
Summary: [b2g-bluetooth] AddReservedServices asserts due to BluetoothService access on DBus Signal thread → [b2g-bluetooth] GetDevicePropertiesInternal asserts due to BluetoothService access on DBus Signal thread
Title fixed.
Summary: [b2g-bluetooth] GetDevicePropertiesInternal asserts due to BluetoothService access on DBus Signal thread → [b2g-bluetooth] DeviceCreated signal asserts due to BluetoothService access on DBus Signal thread
blocking-basecamp: --- → ?
Took the opportunity to do a little code cleanup too. Should condense the async generic getproperties call at some point too.
Attachment #661922 - Attachment is obsolete: true
Attachment #661922 - Flags: review?(echou)
Attachment #661972 - Flags: review?(echou)
Comment on attachment 661972 [details] [diff] [review] Patch 1 (v2) - Move DeviceProperties fetching to a runnable dispatched to the main thread Review of attachment 661972 [details] [diff] [review]: ----------------------------------------------------------------- r+ after problem fixed. ::: dom/bluetooth/linux/BluetoothDBusService.cpp @@ +873,5 @@ > + MOZ_ASSERT(!NS_IsMainThread()); > + nsString replyError; > + DBusError err; > + dbus_error_init(&err); > + Nit: additional blanks here @@ +881,5 @@ > + NS_ConvertUTF16toUTF8(aPath).get(), > + aIface, > + "GetProperties", > + DBUS_TYPE_INVALID); > + if(aIface == DBUS_DEVICE_IFACE) { Nit: needs a blank behind 'if' @@ +891,5 @@ > + } else { > + NS_WARNING("Unknown interface for GetProperties!"); > + return false; > + } > + Nit: additional blanks here @@ +1363,5 @@ > NS_IMETHOD Run() > { > MOZ_ASSERT(!NS_IsMainThread()); > + BluetoothValue v; > + if(!GetPropertiesInternal(mDevicePath, DBUS_DEVICE_IFACE, v)) Nit: needs a blank behind 'if' @@ +1364,5 @@ > { > MOZ_ASSERT(!NS_IsMainThread()); > + BluetoothValue v; > + if(!GetPropertiesInternal(mDevicePath, DBUS_DEVICE_IFACE, v)) > + { Nit: open brace should be at the end of previous line @@ +1407,5 @@ > BluetoothValue values = InfallibleTArray<BluetoothNamedValue>(); > > for (int i = 0; i < mDeviceAddresses.Length(); i++) { > + BluetoothValue v; > + if(!GetPropertiesInternal(mDeviceAddresses[i], DBUS_DEVICE_IFACE, v)) Nit: needs a blank behind 'if' @@ +1408,5 @@ > > for (int i = 0; i < mDeviceAddresses.Length(); i++) { > + BluetoothValue v; > + if(!GetPropertiesInternal(mDeviceAddresses[i], DBUS_DEVICE_IFACE, v)) > + { Nit: open brace should be at the end of previous line @@ +1409,5 @@ > for (int i = 0; i < mDeviceAddresses.Length(); i++) { > + BluetoothValue v; > + if(!GetPropertiesInternal(mDeviceAddresses[i], DBUS_DEVICE_IFACE, v)) > + { > + NS_WARNING("Getting properties failed!"); I think we still need to do DispatchBluetoothReply() here?
Attachment #661972 - Flags: review?(echou) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Wouldn't want this to regress.
blocking-basecamp: ? → +
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: