[Bluetooth] File transfer functions fail after receiving one file.

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
Bluetooth
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: brsun, Assigned: tzimmermann)

Tracking

({smoketest})

unspecified
2.2 S4 (23jan)
ARM
Gonk (Firefox OS)
smoketest

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
This bug is separated from [1]. File transfer functions broken if the device has received one file before. Need to disable and enable Bluetooth from Setting app to make it work again.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1123676#c18
Assignee: nobody → tzimmermann
Status: NEW → ASSIGNED
We are leaking file descriptors in bluetoothd, but fixing this doesn't fix the overall problem. I also see

> I/GeckoBluetooth(  211): OnError: BluetoothSocketInterface::Accept failed: 1

in the logcat.
After transferring the first file, Gecko calls 'listen' again. Bluedroid logs:

> E/bt-btif ( 1432): rfc channel:12 already in use
> E/bt-btif ( 1432): jv_dm_cback: cannot start server, slot found:0xb6e1e218

The accept operation on the listen socket fails afterwards.
Some more logs below: After the first file transfer ended, Gecko tries to create a new listen socket. Bluedroid returns a socket file descriptor, but seems unable to establish the resources (server) afterwards. Reading from the socket in Gecko fails with errno 11 (EAGAIN).

>>>>>

I/GeckoBluetooth(  208): OnSocketDisconnect: virtual void mozilla::dom::bluetooth::BluetoothOppManager::OnSocketDisconnect(mozilla::dom::bluetooth::BluetoothSocket*):1444                                                                                                                                                    
I/GeckoBluetooth(  208): OnSocketDisconnect: [server]
E/bluetoothd( 1373): cmd SOCKET::Listen
E/bluetoothd( 1373): cmd SOCKET::Listen success
E/bt-btif ( 1373): rfc channel:12 already in use
E/bt-btif ( 1373): jv_dm_cback: cannot start server, slot found:0xb6dfb218
I/GeckoBluetooth(  208): Listen: void mozilla::dom::bluetooth::DroidSocketImpl::Listen(int):270 fd=135
I/GeckoBluetooth(  208): Run: virtual nsresult AcceptRunnable::Run():430 fd=135
I/GeckoBluetooth(  208): OnFileCanReadWithoutBlocking: virtual void mozilla::dom::bluetooth::SocketMessageWatcher::OnFileCanReadWithoutBlocking(int):68 fd=135 len=0                                                                                                                                                          
I/GeckoBluetooth(  208): RecvMsg1: mozilla::dom::bluetooth::BluetoothStatus mozilla::dom::bluetooth::SocketMessageWatcher::RecvMsg1():188 fd=135 errno=11 Try again                                                                                                                                                           
I/GeckoBluetooth(  208): OnError: BluetoothSocketInterface::Accept failed: 1
I/GeckoBluetooth(  208): OnSocketDisconnect: virtual void mozilla::dom::bluetooth::BluetoothOppManager::OnSocketDisconnect(mozilla::dom::bluetooth::BluetoothSocket*):1444
That rfc channel #12 is OPUSH and defined by BluetoothReservedChannel::OPUSH.
Created attachment 8553757 [details]
Github pull request

The bug actually was the resource leakage, as I initially suspected.

When the file descriptor gets transfered to Gecko, bluetoothd keeps its own reference around. We need to close it to make Bluedroid free it's internal resources appropriately. Otherwise, the connection is still open, Bluedroid keeps the resources allocated and cannot establish a new socket.
Attachment #8553757 - Flags: review?(shuang)
We need this fix in v2.2 to make Bluetooth File Transfers work correctly.
Attachment #8553757 - Flags: review?(shuang) → review+
Keywords: checkin-needed
Duplicate of this bug: 1124770
Comment on attachment 8553757 [details]
Github pull request

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Introduce bluetooth daemon
User impact if declined: OPP file transfer if sending one file and receive again
Testing completed: Check underlying fd can be released
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch:none
Attachment #8553757 - Flags: approval-mozilla-b2g37?
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → affected
status-b2g-v2.2: unaffected → affected
Adding 'smoketest' keyword from resolved duplicate 1124770
Keywords: smoketest
Master: https://github.com/mozilla-b2g/platform_system_bluetoothd/commit/dcb7c6ba2c6aec23a76d95094c4cbc17eeca5d44
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-b2g-master: affected → fixed
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S4 (23jan)

Updated

3 years ago
Attachment #8553757 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+

Updated

3 years ago
blocking-b2g: 2.2? → 2.2+
v2.2: https://github.com/mozilla-b2g/platform_system_bluetoothd/commit/5e7844e1884e06299543703ce43698c650f04f93
status-b2g-v2.2: affected → fixed
This issue is still reproducing on today's nightly for flame 3.0 devices:
Results: When attempting to transfer a second file, the bluetooth request immediately fails.

--------------------------------------------------
Environmental Variables:
Device: Flame 3.0
BuildID: 20150126010231
Gaia: 0f662dffef27599443cfcd790c2b39190a2b35c8
Gecko: fa91879c8428
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
--------------------------------------------------
Repro: 3/3
QA Whiteboard: [failed-verification]
comment#12 reproducing this issue was a result of a OTA performed between Friday's build of the 23rd (before the fix) to today's build of the 26th.

Upon full flashing the build with the flame image avaliable from the pvt_builds site, the issue is NO LONGER REPRODUCING.
Results: Multiple file transfers can be performed in succession via bluetooth.

--------------------------------------------------
Environmental Variables:
Device: Flame 3.0
BuildID: 20150126010231
Gaia: 0f662dffef27599443cfcd790c2b39190a2b35c8
Gecko: fa91879c8428
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
--------------------------------------------------
Repro: 4/4

Verifying fix in 3.0 build and removing now invalid QA Whiteboard tag.
Status: RESOLVED → VERIFIED
QA Whiteboard: [failed-verification]
status-b2g-master: fixed → verified
Issue NO LONGER REPROES on flame 2.2 devices.
Results: Multiple file transfers can be performed in succession via bluetooth.

--------------------------------------------------
Environmental Variables:
Device: Flame 2.2
BuildID: 20150127002504
Gaia: 80d5b797fd0497a7e3337b7798a21b2e1219681a
Gecko: 01bf1516a65b
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
--------------------------------------------------
Repro: 4/4

Verifying fix on flame 2.2 devices.
status-b2g-v2.2: fixed → verified
Duplicate of this bug: 1126672
Duplicate of this bug: 1129693
You need to log in before you can comment on or make changes to this bug.