reproduce steps: 1. connected with a bluetooth headset and play music via a2dp 2. go to settings, select one searched device(A) to trigger pairing 3. press search device button during pairing 4. select the same device (A) to pair again test result: bluetooth setting UI will exit after step 4

Dear, I have checked the bluedroid log, and have not found any exception. need your help to check why UI will exit. thanks a lots

The probability to repro this bug is around 1/10. 07-22 14:06:12.010 109 109 I GeckoBluetooth: ReplyStatusError: error code(4) 07-22 14:06:12.010 109 109 I Gecko : IPDL protocol error: Handler for PBluetoothRequest returned error code 07-22 14:06:12.010 109 109 I Gecko : 07-22 14:06:12.010 109 109 I Gecko : ###!!! [Parent][DispatchAsyncMessage] Error: Processing error: message was deserialized, but the handler returned false (indicating failure) 07-22 14:06:12.010 109 109 I Gecko : 07-22 14:06:12.020 109 329 I Gecko : [Parent 109] WARNING: waitpid failed pid:710 errno:10: file ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 07-22 14:06:12.260 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: AppWindow][Settings][195.031] Handling mozbrowsererror event... 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: AppWindow][Settings][195.038] Handling mozbrowsererror event... 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: AppWindow][Settings][195.040] publishing internal event: crashed 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: AppWindow][Settings][195.041] publishing external event: crashed 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:371 in aw_kill: kill Settings 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: AppWindow][Settings][195.053] publishing internal event: requestclose Hi Ben&Shawn, can you check log in gecko side?

This might be related to bug 1053107.

I think that dolphin is using v1.4, but bug 1053107, it happened on master, right?

Oh, OK. Then sorry for the noise. It just looked so similar.

Hi Shawn, As discussed last time, would like to know if you have some insights here on whether or not there's a more serious problem underlying.

(In reply to Xinhe Yan from comment #3) > The probability to repro this bug is around 1/10. > > 07-22 14:06:12.010 109 109 I GeckoBluetooth: ReplyStatusError: error > code(4) > > 07-22 14:06:12.010 109 109 I Gecko : IPDL protocol error: Handler for > PBluetoothRequest returned error code > 07-22 14:06:12.010 109 109 I Gecko : > 07-22 14:06:12.010 109 109 I Gecko : ###!!! > [Parent][DispatchAsyncMessage] Error: Processing error: message was > deserialized, but the handler returned false (indicating failure) > 07-22 14:06:12.010 109 109 I Gecko : > 07-22 14:06:12.020 109 329 I Gecko : [Parent 109] WARNING: waitpid > failed pid:710 errno:10: file > ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 > > > 07-22 14:06:12.260 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > AppWindow][Settings][195.031] Handling mozbrowsererror event... > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > AppWindow][Settings][195.038] Handling mozbrowsererror event... > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > AppWindow][Settings][195.040] publishing internal event: crashed > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > AppWindow][Settings][195.041] publishing external event: crashed > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:371 in aw_kill: kill Settings > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > AppWindow][Settings][195.053] publishing internal event: requestclose > > Hi Ben&Shawn, can you check log in gecko side? Hi Xinhe, I played around near two days, and I cannot hit Settings exit problem, maybe something related to IPC crash (at BluetoothChild). At your side, do you see any minidump generated? Or can you attach gdb to Settings application. ./run-gdb.sh attach <<Settings app pid>>

(In reply to yi.zeng from comment #0) > reproduce steps: > 1. connected with a bluetooth headset and play music via a2dp > 2. go to settings, select one searched device(A) to trigger pairing > 3. press search device button during pairing > 4. select the same device (A) to pair again > > test result: > bluetooth setting UI will exit after step 4 > 3. press search device button during pairing I'm a bit confused about this step 3. During pairing, UI will be blocked by pairing confirmation dialog, how can you press search device button? > 4. select the same device (A) to pair again

> [Parent][DispatchAsyncMessage] Error: Processing error: message was > deserialized, but the handler returned false (indicating failure) > 07-22 14:06:12.010 109 109 I Gecko : > 07-22 14:06:12.020 109 329 I Gecko : [Parent 109] WARNING: waitpid > failed pid:710 errno:10: file > ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 > This looks like IPC problem. And we probably need to check stack trace to find out more evidence.

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #9) > (In reply to yi.zeng from comment #0) > reproduce steps: > 1. connected with > a bluetooth headset and play music via a2dp > 2. go to settings, select one > searched device(A) to trigger pairing > 3. press search device button during > pairing > 4. select the same device (A) to pair again > > test result: > > bluetooth setting UI will exit after step 4 > 3. press search device button > during pairing I'm a bit confused about this step 3. During pairing, UI will > be blocked by pairing confirmation dialog, how can you press search device > button? yes, it a little trouble to do this. you need to do step 3 immediately after step 2, before the pairing dialog show. > 4. select the same device (A) to pair again

(In reply to yi.zeng from comment #11) > I'm a bit confused about this step 3. > During pairing, UI will > > be blocked by pairing confirmation dialog, how can you press search device > > button? > yes, it a little trouble to do this. you need to do step 3 immediately after > step 2, before the pairing dialog show. > > 4. select the same device (A) to pair again Maybe this is a good point to check, we never attempt to start discovery before pairing dialog shows up. On other platforms, this is hard to do this, since pairing request immediately returned and basically UI doesn't give user a chance to do so. Good suggestion, i will try this way.

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #12) > Maybe this is a > good point to check, we never attempt to start discovery before pairing > dialog shows up. On other platforms, this is hard to do this, since pairing > request immediately returned and basically UI doesn't give user a chance to > do so. > Good suggestion, i will try this way. yes, it depends on cpu performance and platforms. I think we should disable discover button while pairing, because bluetooth chip is hard to support pairing and searching at the same time. and doing pairing and searching at the same time will cause state panic in bluedroid stack. Acturally, android settings has disabled it, and FFOS settings will cancel discover before pairing(does not disable the button).

(In reply to yi.zeng from comment #13) > (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #12) > > Maybe this is a > > good point to check, we never attempt to start discovery before pairing > > dialog shows up. On other platforms, this is hard to do this, since pairing > > request immediately returned and basically UI doesn't give user a chance to > > do so. > > Good suggestion, i will try this way. > > yes, it depends on cpu performance and platforms. > I think we should disable discover button while pairing, because bluetooth > chip is hard to support pairing and searching at the same time. and doing > pairing and searching at the same time will cause state panic in bluedroid > stack. > Acturally, android settings has disabled it, and FFOS settings will cancel > discover before pairing(does not disable the button). That will make sense to me. We probably need to ask Gaia people to check this part in parallel. Meanwhile, Gecko side needs to figure out why IPC mess up. Ian, is it feasible to disable bluetooth discovery button during pairing procedure?

In this use case, a user click device item for pairing. Then, we can reach the timing to disable discovery button. But, we don't know the timing for re-enable the button. There is no 'pair-completely' event for it. I would not like to do the solution here.

I have changed it locally, you can refer to this attachments. it has been verified by our tester, have not found any side effect until now.

2. go to settings, select one searched device(A) to trigger pairing 3. press search device button during pairing 4. select the same device (A) to pair again When step 3: Press Search device button during pairing, the discovery list will be refresh and clear, and I can't proceed step 4.

(In reply to Ian Liu [:ianliu][PTO 8/22 ~ 8/27] from comment #15) > In this use case, a user click device item for pairing. Then, we can reach > the timing to disable discovery button. But, we don't know the timing for > re-enable the button. There is no 'pair-completely' event for it. I would > not like to do the solution here. Dear lanLiu: Do you have any better suggestion. This problem is very urgent, thank you very much!

Hi, yi.zeng Do you have any suggestion based on my question (Comment 17)?

(In reply to Shufang.Xu from comment #18) > Dear lanLiu: > > Do you have any better suggestion. This problem is very urgent, thank you > very much! We have discussed and agreed on this in the meeting with your team, this is definitely not very urgent. Thank you for your enthusiasm but we need to prioritize and focus on more serious bugs. We would also like to know if you're able to reproduce the same symptom with other steps.

Comment on attachment 8476592 [details] [diff] [review] 331745.patch This patch is hacking for pairing process with a new flag. As comment 15 mention before, we cannot identify a completed pairing process without API. I would not like to feedback it for a non-blocking issue. Leave feedback flag here.

(In reply to Shawn Huang [:shawnjohnjr] from comment #8) > (In reply to Xinhe Yan from comment #3) > > The probability to repro this bug is around 1/10. > > > > 07-22 14:06:12.010 109 109 I GeckoBluetooth: ReplyStatusError: error > > code(4) > > > > 07-22 14:06:12.010 109 109 I Gecko : IPDL protocol error: Handler for > > PBluetoothRequest returned error code > > 07-22 14:06:12.010 109 109 I Gecko : > > 07-22 14:06:12.010 109 109 I Gecko : ###!!! > > [Parent][DispatchAsyncMessage] Error: Processing error: message was > > deserialized, but the handler returned false (indicating failure) > > 07-22 14:06:12.010 109 109 I Gecko : > > 07-22 14:06:12.020 109 329 I Gecko : [Parent 109] WARNING: waitpid > > failed pid:710 errno:10: file > > ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261 > > > > > > 07-22 14:06:12.260 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > > AppWindow][Settings][195.031] Handling mozbrowsererror event... > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > > AppWindow][Settings][195.038] Handling mozbrowsererror event... > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > > AppWindow][Settings][195.040] publishing internal event: crashed > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > > AppWindow][Settings][195.041] publishing external event: crashed > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:371 in aw_kill: kill Settings > > > > 07-22 14:06:12.270 109 109 E GeckoConsole: Content JS LOG at > > app://system.gaiamobile.org/js/app_window.js:804 in aw_debug: [Dump: > > AppWindow][Settings][195.053] publishing internal event: requestclose > > > > Hi Ben&Shawn, can you check log in gecko side? > > Hi Xinhe, > I played around near two days, and I cannot hit Settings exit problem, maybe > something related to IPC crash (at BluetoothChild). At your side, do you see > any minidump generated? Or can you attach gdb to Settings application. > > ./run-gdb.sh attach <<Settings app pid>> Finally we figure the crash pattern. It caused by directly returned NS_ERROR_FAILURE. This makes IPC exception. So it should be returned NS_OK.

It looks like cacnel_discovery fail and ReplyStatusError with NS_ERROR_FAILURE. 07-22 14:06:12.010 109 109 I bt-btif : btif_dm_cancel_discovery 07-22 14:06:12.010 109 109 I GeckoBluetooth: ReplyStatusError: error code(4) 07-22 14:06:12.010 109 109 I Gecko : IPDL protocol error: Handler for PBluetoothRequest returned error code 07-22 14:06:12.010 109 109 I Gecko : 07-22 14:06:12.010 109 109 I Gecko : ###!!! [Parent][DispatchAsyncMessage] Error: Processing error: message was deserialized, but the handler returned false (indicating failure) 07-22 14:06:12.010 109 109 I Gecko : 07-22 14:06:12.020 109 329 I Gecko : [Parent 109] WARNING: waitpid failed pid:710 errno:10: file ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261