From: Johan Hedberg <johan.hedberg@gmail.com>
To: Manuel Naranjo <manuel@aircable.net>
Cc: BlueZ <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH][RFC] Fix SDP resolving segfault
Date: Wed, 21 Jul 2010 13:19:34 +0300 [thread overview]
Message-ID: <20100721101934.GA12188@jh-x301> (raw)
In-Reply-To: <4C46324D.5070800@aircable.net>
Hi Manuel,
On Tue, Jul 20, 2010, Manuel Naranjo wrote:
> I think this patch fixes the weird segfault I had been experiencing
> for the last few months.
Thanks for the patch proposal. It seems like you're trying to to fix the
issue by doing all sorts of minor tweaks here and there, i.e. it seems
like there isn't a full understanding of the real root cause.
> - if (ctxt->cb)
> + if (ctxt->cb && ctxt->user_data)
> ctxt->cb(recs, err, ctxt->user_data);
This part isn't right. It should be perfectly fine for a discovery
requester to pass NULL as user_data and still expect its callback to get
called.
> - if (ctxt->cb)
> + if (ctxt->cb && ctxt->user_data)
> ctxt->cb(NULL, err, ctxt->user_data);
Same here.
> @@ -254,6 +256,8 @@ static gboolean connect_watch(GIOChannel *chan, GIOCondition cond, gpointer user
> int sk, err = 0;
>
> sk = g_io_channel_unix_get_fd(chan);
> + if (ctxt->io_id)
> + g_source_remove(ctxt->io_id);
connect_watch returns FALSE in all cases which will remove the GSource.
So the change you're doing seems redundant.
> - if (ctxt->cb)
> + if (ctxt->cb && ctxt->user_data)
> ctxt->cb(NULL, -err, ctxt->user_data);
Same issue with NULL user_data being valid.
> @@ -391,11 +395,13 @@ int bt_cancel_discovery(const bdaddr_t *src, const bdaddr_t *dst)
> return -ENODATA;
>
> ctxt = match->data;
> - if (!ctxt->session)
> - return -ENOTCONN;
>
> if (ctxt->io_id)
> g_source_remove(ctxt->io_id);
> + ctxt->io_id = 0;
> +
> + if (!ctxt->session)
> + return -ENOTCONN;
>
> if (ctxt->session)
> sdp_close(ctxt->session);
I don't really understand the need for these changes, but admitedly the
function does have issues since it first checks for !ctxt->session and
then later for ctxt->session even though at that point it's already
guaranteed that ctxt->session is not NULL.
Johan
next prev parent reply other threads:[~2010-07-21 10:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 23:33 [PATCH][RFC] Fix SDP resolving segfault Manuel Naranjo
2010-07-21 10:19 ` Johan Hedberg [this message]
2010-07-21 13:26 ` Luiz Augusto von Dentz
2010-07-21 15:15 ` Manuel Naranjo
2010-07-21 15:11 ` Manuel Naranjo
2010-07-23 20:37 ` Luiz Augusto von Dentz
2010-07-28 14:55 ` Luiz Augusto von Dentz
2010-07-28 16:17 ` Manuel Naranjo
2010-07-28 18:46 ` Manuel Naranjo
2010-07-29 8:53 ` Luiz Augusto von Dentz
2010-07-29 13:34 ` Manuel Naranjo
2010-08-03 13:21 ` Manuel Naranjo
2010-08-03 20:17 ` Luiz Augusto von Dentz
2010-08-03 20:24 ` Manuel Naranjo
2010-08-05 14:48 ` Manuel Naranjo
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=20100721101934.GA12188@jh-x301 \
--to=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=manuel@aircable.net \
/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).