Bruce Sun [:brsun] Reporter
	Description • 9 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

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 1 • 9 years ago

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.

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 2 • 9 years ago

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.

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 3 • 9 years ago

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

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 4 • 9 years ago

That rfc channel #12 is OPUSH and defined by BluetoothReservedChannel::OPUSH.

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 5 • 9 years ago

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.

	Thomas Zimmermann [:tzimmermann] [:tdz] Assignee
	Comment 6 • 9 years ago

We need this fix in v2.2 to make Bluetooth File Transfers work correctly.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 8 • 9 years ago

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

	Oliver Nelson [:oliverthor]
	Comment 9 • 9 years ago

Adding 'smoketest' keyword from resolved duplicate 1124770

	Ryan VanderMeulen [:RyanVM]
	Comment 10 • 9 years ago

Master: https://github.com/mozilla-b2g/platform_system_bluetoothd/commit/dcb7c6ba2c6aec23a76d95094c4cbc17eeca5d44

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 9 years ago

v2.2: https://github.com/mozilla-b2g/platform_system_bluetoothd/commit/5e7844e1884e06299543703ce43698c650f04f93

	Oliver Nelson [:oliverthor]
	Comment 12 • 9 years ago

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

	Oliver Nelson [:oliverthor]
	Comment 13 • 9 years ago

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.

	Oliver Nelson [:oliverthor]
	Comment 14 • 9 years ago

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.