Closed Bug 1150330 Opened 10 years ago Closed 10 years ago

[Woodduck]Reply NS_OK if stopDiscovery fails

Categories

(Firefox OS Graveyard :: Bluetooth, defect, P2)

defect

Tracking

(blocking-b2g:2.0M+, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.0M fixed, b2g-v2.1 unaffected, b2g-v2.1S unaffected, b2g-v2.2 unaffected, b2g-master unaffected)

RESOLVED FIXED
blocking-b2g 2.0M+
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.0M --- fixed
b2g-v2.1 --- unaffected
b2g-v2.1S --- unaffected
b2g-v2.2 --- unaffected
b2g-master --- unaffected

People

(Reporter: sync-1, Assigned: shawnjohnjr)

References

Details

(Whiteboard: [2.0m_Only])

Attachments

(1 file, 2 obsolete files)

我们在产线上进行蓝牙测试的时候,发现很容易出现程序崩溃,返回主菜单的情况,但是在研发的环境测试没有出现这样的情况,我们怀疑工厂的环境是由于打开的蓝牙太多了,导致搜索出现问题,看log有: 03-30 12:50:44.724 167 167 E BTIF_CORE: [btmtk_gap_cancel_discovery] failed! 03-30 12:50:44.724 167 167 I GeckoBluetooth: ReplyStatusError: error code(1) 的报错,麻烦帮忙分析一下原因,附件是抓取的log。请查收。 CONTACT INFO (Name,Phone number): DEFECT DESCRIPTION: REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:
After performing Cancel discovery, cancel discovery fail. 03-30 12:50:44.724 167 167 I BTIF_CORE: +++[btif_dm_cancel_discovery]+++! 03-30 12:50:44.724 167 167 I bt_gap_api.c: [GAP] btmtk_gap_cancel_discovery! 03-30 12:50:44.724 167 167 I bt_gap_api.c: [GAP] btmtk_gap_cancel_discovery return:0! 03-30 12:50:44.724 167 167 E BTIF_CORE: [btmtk_gap_cancel_discovery] failed! 03-30 12:50:44.724 167 167 I GeckoBluetooth: ReplyStatusError: error code(1) 03-30 12:50:44.724 167 167 I Gecko : IPDL protocol error: Handler for PBluetoothRequest returned error code 03-30 12:50:44.724 167 167 I Gecko : 03-30 12:50:44.724 167 167 I Gecko : ###!!! [Parent][DispatchAsyncMessage] Error: (msgtype=0xA000A,name=PBluetooth::Msg_PBluetoothRequestConstructor) Processing error: message was deserialized, but the handler returned false (indicating failure) 03-30 12:50:44.724 167 167 I Gecko : 03-30 12:50:44.725 167 455 I Gecko : [Parent 167] WARNING: waitpid failed pid:1381 errno:10: file /home/local/build/fire2-35-release/v7H1U/gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 03-30 12:50:44.734 167 455 I Gecko : [Parent 167] WARNING: pipe error (194): Connection reset by peer: file /home/local/build/fire2-35-release/v7H1U/gecko/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 450 03-30 12:50:44.734 167 167 I Gecko : 03-30 12:50:44.734 167 167 I Gecko : ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv 03-30 12:50:44.734 167 167 I Gecko :
Assignee: nobody → shuang
blueototh stack side comments: 1. BT stack在某次上层cancel discovery正常后仍然上报了一个device, 但是上层在收到”DISCOVERY STOPED”后再次下 discovery cancel. 需要上层Check这个操作。 03-30 12:50:59.731 167 711 D bt_gap_hdl.c: HAL bt_hal_cbacks->device_found_cb 03-30 12:50:59.732 167 711 I bt_gap_hdl.c: ---[GAP] btmtk_handle_gap_message---! 03-30 12:50:59.735 167 711 I bt_gap_hdl.c: +++[GAP] btmtk_handle_gap_message msg:[MSG_ID_BT_BM_DISCOVERY_CANCEL_CNF]+++! 03-30 12:50:59.735 167 711 D bt_gap_hdl.c: HAL bt_hal_cbacks->discovery_state_changed_cb // call back “DISCOVERY STOPED” 03-30 12:50:59.735 167 711 I bt_gap_hdl.c: ---[GAP] btmtk_handle_gap_message---! 03-30 12:50:59.748 167 167 I bt_gap_api.c: [GAP] btmtk_gap_cancel_discovery! 03-30 12:50:59.748 167 167 I bt_gap_api.c: [GAP] btmtk_gap_cancel_discovery return:0! 03-30 12:50:59.748 167 167 E BTIF_CORE: [btmtk_gap_cancel_discovery] failed! 2. 上层在某次stack返回”DISCOVERY STOPED”后再次连续下了cancel discovery. 需要上层check. 03-30 12:50:44.678 167 711 I bt_gap_hdl.c: +++[GAP] btmtk_handle_gap_message msg:[MSG_ID_BT_BM_DISCOVERY_CANCEL_CNF]+++! 03-30 12:50:44.678 167 711 D bt_gap_hdl.c: HAL bt_hal_cbacks->discovery_state_changed_cb// call back “DISCOVERY STOPED”
Summary: [FFOS2.0][Woodduck][BT_Issue] Bluetooth failer → [FFOS2.0][Woodduck]Ignore redundant stopDiscovery request if current Discovering state is not started
Summary: [FFOS2.0][Woodduck]Ignore redundant stopDiscovery request if current Discovering state is not started → [Woodduck]Ignore redundant stopDiscovery request if current Discovering state is not started
Summary: [Woodduck]Ignore redundant stopDiscovery request if current Discovering state is not started → [Woodduck]Reply NS_OK if stopDiscovery fails
Attachment #8587189 - Attachment is obsolete: true
Attachment #8587189 - Flags: feedback?(brsun)
Don't reply NS_ERROR_FAILURE, this avoid IPC code exit unexpectedly. 03-30 12:50:44.724 167 167 I GeckoBluetooth: ReplyStatusError: error code(1) 03-30 12:50:44.724 167 167 I Gecko : IPDL protocol error: Handler for PBluetoothRequest returned error code 03-30 12:50:44.724 167 167 I Gecko : 03-30 12:50:44.724 167 167 I Gecko : ###!!! [Parent][DispatchAsyncMessage] Error: (msgtype=0xA000A,name=PBluetooth::Msg_PBluetoothRequestConstructor) Processing error: message was deserialized, but the handler returned false (indicating failure) 03-30 12:50:44.724 167 167 I Gecko : 03-30 12:50:44.725 167 455 I Gecko : [Parent 167] WARNING: waitpid failed pid:1381 errno:10: file /home/local/build/fire2-35-release/v7H1U/gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 03-30 12:50:44.734 167 455 I Gecko : [Parent 167] WARNING: pipe error (194): Connection reset by peer: file /home/local/build/fire2-35-release/v7H1U/gecko/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 450 03-30 12:50:44.734 167 167 I Gecko : 03-30 12:50:44.734 167 167 I Gecko : ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
Comment on attachment 8587209 [details] [diff] [review] Bug 1150330 - [Woodduck]Reply NS_OK if stopDiscovery fails Review of attachment 8587209 [details] [diff] [review]: ----------------------------------------------------------------- LGTM
Attachment #8587209 - Flags: review?(brsun) → review+
Component: Gaia::Bluetooth File Transfer → Bluetooth
I locally test this patch, by modifying gaia code and maliciously call multiple stopDiscovery.
Can you apply this patch and try?
Flags: needinfo?(sync-1)
I'm waiting for bug reporter's feedback, if this can fix their problems, I will land v.2.0m.
已解决,此问题可以关闭 I2aac433fd814d5aaccd21d1b755afe66861901ae
Hi Shawn, Is this 2.0M only issue? SHould we also land this on master? Thanks!
blocking-b2g: --- → 2.0M+
Flags: needinfo?(shuang)
Status: NEW → ASSIGNED
Blocks: Woodduck
(In reply to Josh Cheng [:josh] from comment #11) > Hi Shawn, > Is this 2.0M only issue? SHould we also land this on master? > Thanks! No. It's not 2.0M only issue. It happened since (Bug 942104 - Notify BluetoothAdapter about discovery state changed) landed.
Flags: needinfo?(sync-1)
Do we expect all the common fix land to v2.0 and v2.1?
Flags: needinfo?(jocheng)
Hi Shawn, If the issue is common issue. I suggest we also land this on master. 2.1 or 2.2 can pick this fix if launch device need this. Thanks!
Flags: needinfo?(jocheng)
(In reply to Josh Cheng [:josh] from comment #15) > Hi Shawn, > If the issue is common issue. I suggest we also land this on master. 2.1 or > 2.2 can pick this fix if launch device need this. > Thanks! m-c already fixed this bug. So we don't need to patch m-c.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(kli)
Resolution: --- → FIXED
Whiteboard: [2.0m_Only]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: