Hi Luiz, At 12:08 08.07.2011, Luiz Augusto von Dentz wrote:
Hi Peter, On Thu, Jul 7, 2011 at 10:57 PM, Peter Kornatowski <pkorn@xxxxxxx> wrote:> I'm calling Acquire when SetConfiguration is called by bluez (isn't that the > correct spot, cause there you get the transport path?). I attached the whole> modified script, so you can see exactly what I'm doing. As I explained in the last email you have to reply to the SetConfiguration before you are able to do Acquire, that is on purpose to avoid a possible deadlock where you are the application is waiting for Acquire to complete but bluetoothd is waiting the application to reply to SetConfiguration, bluetoothd won't block but the application may block trying to Acquire and by doing that it is not able to reply to SetConfiguration.
This is why I'm calling Acquire asynchronously. But ok, I will test it with a postponed Acquire.
> It also works for the first headset or if all headsets are in connected mode> and you start the script, so generally it should be ok. > But it doesn't work if you start the script and then connect the first > headset (or start the script after just one headset is in connected mode). > Then the headset gets into playing mode, but bluez tries to put it into > playing mode on the other endpoint, too (at least it looks that way to me > cause SetConfiguration is being called twice). So then Acquire is being> called twice, too. For one call I get the file descriptor, but for the other> call I get "Operation Not Authorized". Maybe because the second > SetConfiguration is called for the other endpoint, which is on the other > adapter with which the headset is not paired (each headset is only paired > with one adapter). On the other hand, the transport path from both > SetConfiguration calls is for the same adapter... But when you then connect > the second headset (which is paired with the other adapter), bluez doesn't > call SetConfiguration for it (probably because this endpoint is still > "blocked" by the first headset, but it shouldn't be). The Operation Not Authorized in because you didn't reply to SetConfiguration, also bluetoothd will try to match the profile capabilities with the endpoint capabilities and then call SetConfiguration to the endpoint to confirm if it is able to handle the transport, in theory I don't see any problem to the same endpoint to get multiple SetConfiguration as long it is for different devices, but perhaps we need to limit to only one transport per endpoint which is usually the case for a2dp since the sep has the in_use flag.
Where do you see that I'm not replying to SetConfiguration? Because of the asynchronous Acquire call it should always reply.
But the limit would probably be a good idea.
> Additionally, when you try to end the script with ctrl+c now, bluetoothd > segfaults with: segfault at 3c ip b75359d5 sp bfd25c10 error 4 in > libdbus-1.so.3.5.7[b7521000+48000] > I tried the whole use case as user and as root, but no difference. I also > attached the syslog output (bluetoothd started with -d). The syslog doesn't seems to indicate any crashes, did you left it out? Btw, to get more information about the crash please run bluetooth with valgrind e.g: sudo G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-module valgrind --trace-children=yes ./bluetoothd -dn
I didn't leave out anything. I attached the valgrind log. This is what I did: 1. Started bluetoothd with valgrind.2. Started simple-endpoint-dual (see my last e-mail) with no headsets in connected mode. 3. Connected one headset (got one file descriptor and one Operation Not Authorized).
4. Ended simple-endpoint-dual with ctrl+c (and bluetoothd segfaults).
-- Luiz Augusto von Dentz --
Peter
Attachment:
bluetoothd_segfault.valgrind
Description: Binary data
