At 21:43 08.07.2011, Peter Kornatowski wrote:
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.
Tested it with a seperate python-script for calling Acquire (attached it). Modified the previous script so that it doesn't call Acquire anymore. So when registering two endpoints and connecting one headset, I see bluez calling SetConfiguration for both endpoints (so two transport paths with just different fdX at the end). I then call Acquire with the new script for one endpoint at get the headset into playing mode every time. When trying to call Acquire for the second headset I always get Operation Not Authorized (which is fine I guess, but the second SetConfiguration call in the first place is not). When stopping this last scquire-script with ctrl+c (just the one that produced Operation Not Authorized), bluetoothd always segfaults. Stopping the other acquire-script or the endpoint-dual doesn't segfault bluetoothd. I could reproduce this with my C code as well.
Also with endpoint and Acquire being in two different scripts I could play around a little and found out that starting more endpoints than there are connected headsets is not a good idea, even when you don't call Acquire. So to workaround this behaviour I have to wait for a headset to connect, then register just one endpoint for it and call Acquire. For the next headset that connects I have to do the same. And when a headset disconnects, the endpoint has to be unregistered and closed as well. Or is this the intended way of doing it anyway?
> 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 -dnI 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:
simple-endpoint-acquire
Description: Binary data
