From: Brian Gix <bgix@codeaurora.org>
To: Anderson Lizardo <anderson.lizardo@openbossa.org>
Cc: Claudio Takahasi <claudio.takahasi@openbossa.org>,
BlueZ development <linux-bluetooth@vger.kernel.org>
Subject: Re: "Conditional jump or move" errors on attrib_create_sdp()
Date: Thu, 24 Feb 2011 10:40:32 -0800 [thread overview]
Message-ID: <4D66A620.3040000@codeaurora.org> (raw)
In-Reply-To: <AANLkTimZKv2D3BZy+QWiutokQUGrnBWWT_uHQ0Lp06n8@mail.gmail.com>
Hi Lizardo,
On 2/24/2011 9:56 AM, Anderson Lizardo wrote:
> Hi Brian,
>
> I just noticed "Conditional jump or move depends on uninitialised
> value(s)" errors when running bluez with valgrind:
>
> ==690== Conditional jump or move depends on uninitialised value(s)
> ==690== at 0x4837EA0: sdp_set_service_id (sdp.c:2456)
> ==690== by 0x166F79: attrib_create_sdp (attrib-server.c:133)
> ==690== by 0x167436: register_core_services (attrib-server.c:856)
> ==690== by 0x1675E3: attrib_server_init (attrib-server.c:902)
> ==690== by 0x162424: main (main.c:462)
>
> Full log is attached, it was generated with:
>
> env G_SLICE=always-malloc valgrind bluetoothd -n -d
>
> Can you take a look at this? Thanks,
This can be fixed in one of about 3 ways:
1. Eliminate the call to sdp_set_service_id all together (it's not
required by the specification)
2. Set the service ID to services UUID (doesn't service a useful purpose)
3. Let the profile deal with the SDP service ID. (same as 1 for now)
The offending code attempts to give the SDP record a "Service ID" which
is not required by the specification, but is useful if there is more
than one instance of the service being declared in SDP.
An example of this in the case of GATT might be Two Primary Battery
meter services, where both would have the same service UUID, but one
would be referring to a "Main" battery, and the other an "Aux" battery.
In LE mode, the Service ID is unavailable and would be superfluous
because everything you need to know about the service can be determined
from the other Attributes. Therefore, I think the argument can be made
that specific instance information is equally superflous, and should not
be included in the service record.
If there are no objections, I am just going to eliminate the call to
sdp_set_service_id in the attribute server all together.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
parent reply other threads:[~2011-02-24 18:40 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <AANLkTimZKv2D3BZy+QWiutokQUGrnBWWT_uHQ0Lp06n8@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D66A620.3040000@codeaurora.org \
--to=bgix@codeaurora.org \
--cc=anderson.lizardo@openbossa.org \
--cc=claudio.takahasi@openbossa.org \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).