New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 779460 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

start_discovery called continuously after stop_discovery failed due to "in progress"

Project Member Reported by josephsih@chromium.org, Oct 30 2017

Issue description

Eve Chrome Version:
CHROMEOS_RELEASE_BUILDER_PATH=eve-release/R62-9901.54.0

Intel firmware: 0xF3

The problem: sometimes, chrome called stop_discovery prior to the completion of the previous start_discovery operation. This would result in "start/stop discovery in progress" busy error. It looks that chrome might not handle the busy error properly such that chrome would then try to call start_discovery continuously without calling stop_discovery again.

What is the expected behavior of chrome: when stop_discovery failed due to busy error, chrome is expected to call stop_discovery again after a while before issuing any start_discovery afterwards.


About the "start/stop discovery in progress" error, refer to Sonny's Related CL: Fix race condition in bluez discovery operations (https://chromium-review.googlesource.com/#/c/chromiumos/third_party/bluez/+/677467/)
  - This CL makes bluetoothd send a busy error ("start/stop discovery in progress") back to chrome.
  - However, it looks that chrome might not handle the busy error properly yet.


----- more explanation below -----

The correct cycles of start_discovery and stop_discovery should look something like 

    (1) calling start_discovery -> 
    (2) receiving start_discovery_complete ->
    (3) calling stop_discovery -> 
    (4) receiving stop_discovery_complete -> 
    (and the above operations loop over and over....)

In /var/log/messages, the correct logs look something like

(1) 2017-10-28T01:23:36.550111+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13
(2) 2017-10-28T01:23:36.646617+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery_complete() status 0x00
(3) 2017-10-28T01:23:37.357681+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() sender :1.13
(4) 2017-10-28T01:23:37.376830+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery_complete() status 0x00


However, if chrome called stop_discovery before start_discovery_complete was received, something bad occurred. In the /var/log/messages,

2017-10-28T02:20:27.674491+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13
2017-10-28T02:20:28.355394+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() sender :1.13
2017-10-28T02:20:28.355419+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() error: start discovery in progress   <-- should call stop_discovery() after a while
2017-10-28T02:20:28.356134+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery_complete() status 0x00
2017-10-28T02:20:28.762814+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13     <-- start_discovery() would not succeed since it was still discovering.
2017-10-28T02:20:32.210088+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13
2017-10-28T02:20:32.625131+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13
... chrome kept calling start_discovery() ... 


When calling stop_discovery(), the error "start discovery in progress" was expected because start_discovery_complete was not received yet. This was fine. 

However, one would expect chrome to call stop_discovery() again after a while to actually stop discovery. However, chromes kept calling start_discovery() continuously. It would fail since the adapter had already been discovering.


The corresponding ui.LATEST log:

[1282:1282:1028/022028.358746:ERROR:device_event_log_impl.cc(156)] [02:20:28.358] Bluetooth: bluetooth_adapter_bluez.cc:1604 /org/bluez/hci0: Failed to stop discovery: org.bluez.Error.InProgress: Operation already in progress                                                                                                                           
[1282:1282:1028/022028.359294:ERROR:ble_scanner.cc(266)] Error stopping discovery session.
[1282:1282:1028/022028.763710:ERROR:device_event_log_impl.cc(156)] [02:20:28.763] Bluetooth: bluetooth_adapter_bluez.cc:1570 /org/bluez/hci0: Failed to start discovery: org.bluez.Error.InProgress: Operation already in progress
[1282:1282:1028/022028.764610:ERROR:ble_scanner.cc(233)] Error starting discovery session. Initialization failed.
... more such errors repeated ...


The tarball of the logs: https://drive.google.com/a/google.com/file/d/1oTjucGns16tXEss2ChLD5P8cx8OKlsg2/view?usp=sharing


 
Status: WontFix (was: Untriaged)
Joseph, thanks for reporting this bug. After looking at the chrome logs, this looks like a bug specific to 62.0.3202.74.

The offending CL has been reverted and relanded with the fix on the next build. Please find my CLs in this list (Fix dangling discovery session during suspend/resume):
https://chromium.googlesource.com/chromium/src/+log/62.0.3202.74..62.0.3202.77?n=10000
Sonny, thanks for looking into and triage the issue! 

Sign in to add a comment