Mantis Bugtracker

Простой вид комментарии ] расширенный вид ] история ] печать ]
Номер Категория Серьезность Воспроизводимость Создан Изменен
0000103 [obex-data-server] General большая не проверялась 2008-07-03 16:40 2008-10-17 19:59
Инициатор skirsdeda Видимость общая  
Ответственный skirsdeda
Приоритет обычный Решение решен  
Состояние закрыт   Версия продукта
Суть 0000103: Problems when selecting different hci dev for session
Подробности Sometimes when connecting session, binding to hci dev fails.
Дополнительные сведения
Tэги Нет прикрепленных тэгов.
Вложенные файлы ? file icon close.patch [^] (1,918 bytes) 2008-07-13 19:43

- Связи

-  Комментарии
heston_james (инициатор)
2008-07-03 17:01

Hi Skirs,

From testing done by myself and kpanic it would seem that this only occurs when session connects fail, I would guess that the session is not properly finalized if it fails to connect, thus leaving dead bondings to the local adapters.

skirsdeda (администратор)
2008-07-03 17:17

In svn rev 1595 I included errno in error message. Try again and see what errno you get in error message.
heston_james (инициатор)
2008-07-03 18:08

org.openobex.Error.ConnectionAttemptFailed, Binding to local device failed (errno: 98))


skirsdeda (администратор)
2008-07-03 18:13

As suspected, we get EADDRINUSE.
heston_james (инициатор)
2008-07-03 18:28

Ok, so do we think this is because the socket isnt being closed when the session fails to connect?

skirsdeda (администратор)
2008-07-03 18:29

yes, either it isn't closed (which I doubt) or we try to connect too early (before it is fully closed)
manuel (инициатор)
2008-07-13 19:42

Hello everyone,

I think it actually it's a collision, bluetooth acl connections aren't closed immediately it takes some seconds to be closed. So if you call connect right after you called close it will lead to those kinds of errors.

Besides there's another problem going on, if you use dbus-python then an object will only be unreferenced when you remove all the signals listeners that it has, so that prevents ods_session_dispose from been called. I created a page in the wiki to show how to avoid this problem: [^] this one isn't yet referenced from the main page, I would like Tadas to review it first. We should add this too all the "official" samples (test codes).

The patch I'm including fixes too thing. One is minor, that when we bind to the local device we should use channel 0, so it's bluez the one that decide which rfcomm channel is free for been used, we only have to force the target channel, not the local one. Bluetooth is smart enough to cross rfcomm ports if needed.

The other part is to make Close from ServerSession to really match the specs, this means that a call to close really closes the socket connection, and not doing it like it's done right now that's waiting until ods_session_dispose is called. I haven't removed close from ods_session_disposse just calling it from ods_session_close and mark it as invalid, so session_dispose doesn't close it.

Please review the patch, comments are welcomed.

Manuel Naranjo
Wireless Cables Inc.
heston_james (инициатор)
2008-07-14 10:55

Good morning Manuel,

Thank you for the Wiki entry, that certainly makes it a lot clearer. I have had problems with that in the past I'm sure where I was reaching the limit of file descriptors but couldnt find out what was causing it, I'm guessing this was the reason. I'll look at implementing that structure into my app, I did speak with the Dbus guys at the time about it but we were never able to trace exactly what I was doing wrong. However, I've not seen those errors in some time now.

I've been shaping up these test scripts this morning, I'm just off out for a short while now but will begin to test when I get back. I'll start by testing with the patch you've attached to see if that makes any difference, failing that I'll try implementing those modifications into my python code.

Iether way we'll be much more informed by the end of the day after we've tested.

What testing, if any, have you had chance to do? and what results have you had?


skirsdeda (администратор)
2008-07-21 15:20

Patch applied in svn (except for socket closing in close(), because session.Close() causes session_finalize to be called just after it anyway). Thanks for patch.

Are all the symptoms of this bug gone with newest svn?
heston_james (инициатор)
2008-07-21 18:14


I've been testing with this svn this morning and been creating hundereds of sessions without it causing any problems, I'm fairly sure that this bug has been fixed by this latest release :-)


skirsdeda (администратор)
2008-07-21 18:15

Marking as resolved then

- история
Дата изменения Пользователь Поле Изменение
2008-07-03 16:40 skirsdeda Новый вопрос
2008-07-03 17:01 heston_james Комментарий добавлен: 0000339
2008-07-03 17:17 skirsdeda Комментарий добавлен: 0000342
2008-07-03 18:08 heston_james Комментарий добавлен: 0000344
2008-07-03 18:13 skirsdeda Комментарий добавлен: 0000346
2008-07-03 18:28 heston_james Комментарий добавлен: 0000348
2008-07-03 18:29 skirsdeda Комментарий добавлен: 0000349
2008-07-13 19:33 manuel Отслеживать: manuel
2008-07-13 19:42 manuel Комментарий добавлен: 0000361
2008-07-13 19:43 manuel Файл добавлен: close.patch
2008-07-14 10:55 heston_james Комментарий добавлен: 0000364
2008-07-21 15:20 skirsdeda Комментарий добавлен: 0000373
2008-07-21 18:14 heston_james Комментарий добавлен: 0000375
2008-07-21 18:15 skirsdeda Состояние новый => отработан
2008-07-21 18:15 skirsdeda Решение открыт => решен
2008-07-21 18:15 skirsdeda Ответственный => skirsdeda
2008-07-21 18:15 skirsdeda Комментарий добавлен: 0000376
2008-07-24 15:00 skirsdeda Целевая версия => 0.4
2008-10-17 19:59 skirsdeda Решен в версии => 0.4
2008-10-17 19:59 skirsdeda Состояние отработан => закрыт

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker