1047322 - [dolphin][Bluetooth] sometimes Bluetooth setting UI will exit

Status: RESOLVED DUPLICATE of bug 1150330

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[yi.zeng]

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

Comment 1

[yi.zeng]

Attachment: BluetoothSettingExit.rar

Comment 2

[yi.zeng]

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

Comment 3

[Xinhe Yan]

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?

Comment 4

[Thomas Zimmermann [:tzimmermann] [:tdz]]

This might be related to bug 1053107.

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 6

[Thomas Zimmermann [:tzimmermann] [:tdz]]

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

Comment 7

[Wayne Chang [:wchang]]

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.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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>>

Comment 9

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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

Comment 10

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

> [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.

Comment 11

[yi.zeng]

(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

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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.

Comment 13

[yi.zeng]

(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).

Comment 14

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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?

Comment 15

[[e-mail], [e-mail]]

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.

Comment 16

[yi.zeng]

Attachment: 331745.patch

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.

Comment 17

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 18

[Shufang.Xu]

(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!

Comment 19

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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

Comment 20

[Wayne Chang [:wchang]]

(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 21

[[e-mail], [e-mail]]

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.

Comment 22

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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.

Comment 23

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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