[Bluetooth] Fix a race which causes a double write request
When testing with Nearby Share we were seeing crashes during Bluetooth socket sending. When ever the crash happened we would see the same write_request getting processed twice. When the write request gets to the underlying socket implementation we would hit this CHECK: [1]. This was happening because SendFrontWriteRequest can get called again while write request is still pending (a call is always queued after write completion regardless of the queue state) and it grabs the front of the queue. The queue item for a write request does not get popped off until the transfer is complete which allows the same request to get processed twice (depending on timing). The solution here is to remove the pending request from the queue right away and store while it is in progress. In SendFrontWriteRequest we check if there is already a pending request and exit early. SendFrontWriteRequest always gets re-queued when the pending write request completes so we always keep processing. Tested on device with transfers between Android and ChromeOS. [1] https://source.chromium.org/chromium/chromium/src/+/master:net/socket/socket_posix.cc;l=331 Fixed: 1121747 Change-Id: I67b69f735798f832aecdd62b6697ecef8d99cfaa Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429863Reviewed-by:Reilly Grant <reillyg@chromium.org> Commit-Queue: James Vecore <vecore@google.com> Cr-Commit-Position: refs/heads/master@{#810749}
Showing
Please register or sign in to comment