Linux bluetooth development
 help / color / mirror / Atom feed
From: Christian Fetzer <christian.fetzer@oss.bmw-carit.de>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/4] obexd: Fix setting message folder for relative folder in ListMessages
Date: Fri, 13 Sep 2013 13:45:12 +0200	[thread overview]
Message-ID: <5232FAC8.5090903@oss.bmw-carit.de> (raw)
In-Reply-To: <CABBYNZL+d8CpQNJ2z750s30naUoY-049XpCs3gOtGMsG1hCJVw@mail.gmail.com>

Hi Luiz,

On 09/13/2013 12:47 PM, Luiz Augusto von Dentz wrote:
> Hi Christian,
> 
> On Fri, Sep 13, 2013 at 12:23 PM, Christian Fetzer
> <christian.fetzer@oss.bmw-carit.de> wrote:
>> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>>
>> The method ListMessages allows to specify a relative subfolder.
>> This subfolder needs to be added to the current path when registering
>> a new message interface.
>> ---
>>  obexd/client/map.c | 19 +++++++++++++++++--
>>  1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/obexd/client/map.c b/obexd/client/map.c
>> index 9a1b140..54011d8 100644
>> --- a/obexd/client/map.c
>> +++ b/obexd/client/map.c
>> @@ -96,6 +96,7 @@ static const char * const filter_list[] = {
>>  struct map_data {
>>         struct obc_session *session;
>>         DBusMessage *msg;
>> +       char *folder;
>>         GHashTable *messages;
>>         int16_t mas_instance_id;
>>         uint8_t supported_message_types;
>> @@ -1058,8 +1059,7 @@ static void msg_element(GMarkupParseContext *ctxt, const char *element,
>>
>>         msg = g_hash_table_lookup(data->messages, values[i]);
>>         if (msg == NULL) {
>> -               msg = map_msg_create(data, values[i],
>> -                                       obc_session_get_folder(data->session));
>> +               msg = map_msg_create(data, values[i], data->folder);
>>                 if (msg == NULL)
>>                         return;
>>         }
>> @@ -1153,6 +1153,19 @@ static void message_listing_cb(struct obc_session *session,
>>  done:
>>         g_dbus_send_message(conn, reply);
>>         dbus_message_unref(map->msg);
>> +       g_free(map->folder);
>> +       map->folder = NULL;
>> +}
>> +
>> +static char *get_absolute_folder(const char *root, const char *subfolder)
>> +{
>> +       if (!subfolder || strlen(subfolder) == 0)
>> +               return g_strdup(root);
>> +       else
>> +               if (g_str_has_suffix(root, "/"))
>> +                       return g_strconcat(root, subfolder, NULL);
>> +               else
>> +                       return g_strconcat(root, "/", subfolder, NULL);
>>  }
>>
>>  static DBusMessage *get_message_listing(struct map_data *map,
>> @@ -1175,6 +1188,8 @@ static DBusMessage *get_message_listing(struct map_data *map,
>>         if (obc_session_queue(map->session, transfer, message_listing_cb, map,
>>                                                                 &err)) {
>>                 map->msg = dbus_message_ref(message);
>> +               map->folder = get_absolute_folder(obc_session_get_folder(
>> +                                                       map->session), folder);
>>                 return NULL;
>>         }
>>
>> --
>> 1.8.3.4
> 
> This will probably not work in case of multiple outstanding requests
> the last will always overwrite the folder, which btw will leak, so
> probably we need a per request data.
> 
> 

Yes, the issue exists already in the current code base, because the stored
dbus message is overridden if any MAP function is called before the previous
one is finished.

I've been able to reproduce a crash with it and already started to write a patch
that adds a pending_request on top of this patch.

Do you prefer to have a fix first and rebase this patchset on it, or do you
prefer to get the notification API patchset first? (which is already ready to be sent)

Christian

  reply	other threads:[~2013-09-13 11:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13  9:23 [PATCH 0/4] obexd: Fix setting message folder Christian Fetzer
2013-09-13  9:23 ` [PATCH 1/4] obexd: Add folder property to map_msg_create Christian Fetzer
2013-09-13 10:11   ` Luiz Augusto von Dentz
2013-09-13 11:33     ` Christian Fetzer
2013-09-13  9:23 ` [PATCH 2/4] obexd: Fix setting message folder for relative folder in ListMessages Christian Fetzer
2013-09-13 10:47   ` Luiz Augusto von Dentz
2013-09-13 11:45     ` Christian Fetzer [this message]
2013-09-13 11:54       ` Luiz Augusto von Dentz
2013-09-13  9:23 ` [PATCH 3/4] obexd: Clarify the folder property of ListMessages Christian Fetzer
2013-09-13  9:23 ` [PATCH 4/4] obexd: Clarify the folder property of PushMessage Christian Fetzer

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=5232FAC8.5090903@oss.bmw-carit.de \
    --to=christian.fetzer@oss.bmw-carit.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /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