Hi Hendrik,
> > > since several versions of bluez userspace libs and utils, I am unable to
> > > unregister local SDP server records. Everything I tried so far fails to
> > > unregister the record:
> > > I use sdp_connect() and sdp_device_record_register() to register the SDP
> > > record and use the return result of the latter for
> > > sdp_device_record_unregister() and then sdp_close().
> > >
> > > In earlier versions, the unregistering and explicit closing of the
> > > session handle wasn't even necessary but that broke. That can be handled
> > > but unregistering a record in an explicit way like above should work,
> > > doesn't it?
> > >
> > > When the bug appeared, I though that waiting some versions might suffice.
> > > But obviously, nobody ever noticed.
> > > Is there a possibility that this gets fixed?
> >
> > not sure about that. Never heard about it. Are you using the sdpd daemon
> > or do you use hcid -s and the embedded SDP server?
> >
> > I might have introduced a bug when switching everything over to the
> > embedded SDP server and the automatic service classes handling. Do you
> > have a simple reproducer that I can try?
>
> Yes, current obexpushd from my repository at
> https://www.hendrik-sattler.de/svn/obexpushd/trunk/
>
> I see this since about 3.11 when that entered Debian testing, current is 3.22.
> I assume that the embedded SDP server might be the cause, at least Debian
> uses it. BTW: kdebluetooth has the same problem.
> I also reported that as Debian bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445677
first of all you are using the unregister function wrongly. You have to
give it the exact record structure you gave the register function. So
when you allocate a new record, then the unregister has no idea what to
do with it.
Why it doesn't cleanup after program termination is unclear to me. That
should actually work. You might wanna investigate on that one.
Regards
Marcel
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Hendrik,
> > first of all you are using the unregister function wrongly. You have to
> > give it the exact record structure you gave the register function. So
> > when you allocate a new record, then the unregister has no idea what to
> > do with it.
>
> Ok, I remember now everything related to the record and it works. One note
> though: the sdp_record_free() function always crashes. Is it actually
> supposed to be used? Or asked the other way: how is one supposed to free the
> previously allocated stuff correctly? Or is this done automatically?
actually I can't remember. There might be some cases where the
unregister function actually frees the record. The SDP code is not
something anybody can be proud of.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Am Donnerstag 20 Dezember 2007 schrieben Sie:
> first of all you are using the unregister function wrongly. You have to
> give it the exact record structure you gave the register function. So
> when you allocate a new record, then the unregister has no idea what to
> do with it.
Ok, I remember now everything related to the record and it works. One note
though: the sdp_record_free() function always crashes. Is it actually
supposed to be used? Or asked the other way: how is one supposed to free the
previously allocated stuff correctly? Or is this done automatically?
> Why it doesn't cleanup after program termination is unclear to me. That
> should actually work. You might wanna investigate on that one.
I will try that, although I took the way of catching SIGINT and SIGTERM, now.
Thanks for your help.
HS
Hi Hendrik,
> > first of all you are using the unregister function wrongly. You have to
> > give it the exact record structure you gave the register function. So
> > when you allocate a new record, then the unregister has no idea what to
> > do with it.
>
> bt_sdp_obexpush() does create a new record structure but with the
> exact same parameters (actually no variable parameters at all). The
> resulting records should fully match, at least I assume that. The
> record ID is then stored in the session_t value, I assume.
> Or are pointer addresses matched, too?
doesn't work like that. The magic is the record->handle and nothing
else. However that might change. So the safest way is to have a static
variable for the record that stores it for the lifetime of the daemon.
> > Why it doesn't cleanup after program termination is unclear to me. That
> > should actually work. You might wanna investigate on that one.
>
> Before this came up, I did not unregister or close at all and
> everything was fine when the program was killed (SDP record was gone).
> Can you give me a hint where this is actually processed, bluez-libs or
> bluez-utils?
It is processed in bluez-utils/sdpd/, but be aware of that this code is
really tricky. I am about to actually remove it at some point. Not sure
when and how though.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoting Marcel Holtmann <[email protected]>:
>> https://www.hendrik-sattler.de/svn/obexpushd/trunk/
>>
>> I see this since about 3.11 when that entered Debian testing, =20
>> current is 3.22.
>> I assume that the embedded SDP server might be the cause, at least Debian
>> uses it. BTW: kdebluetooth has the same problem.
>> I also reported that as Debian bug report
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D445677
>
> first of all you are using the unregister function wrongly. You have to
> give it the exact record structure you gave the register function. So
> when you allocate a new record, then the unregister has no idea what to
> do with it.
bt_sdp_obexpush() does create a new record structure but with the =20
exact same parameters (actually no variable parameters at all). The =20
resulting records should fully match, at least I assume that. The =20
record ID is then stored in the session_t value, I assume.
Or are pointer addresses matched, too?
> Why it doesn't cleanup after program termination is unclear to me. That
> should actually work. You might wanna investigate on that one.
Before this came up, I did not unregister or close at all and =20
everything was fine when the program was killed (SDP record was gone).
Can you give me a hint where this is actually processed, bluez-libs or =20
bluez-utils?
Thanks
HS