2011-03-11 10:24:55

by Radoslaw Jablonski

Subject: [PATCH] Change order of freeing contacts data in send_pull_part

Moved freeing data->contacts before asynchronous data sending
is triggered via data->cb callback.
This data is no longer needed anyway after vcards are generated
and freeing it later may cause race condition (because freeing
this data need to be handled also in phonebook_req_finalize to
avoid memory leaks when client disconnects in the middle of
retrieving contacts from db).
---
plugins/phonebook-tracker.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 2fced7a..f241cb4 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1576,13 +1576,16 @@ static void send_pull_part(struct phonebook_data *data,
const struct apparam_field *params, gboolean lastpart)
{
GString *vcards;
+ int amount;

DBG("");
vcards = gen_vcards(data->contacts, params);
- data->cb(vcards->str, vcards->len, g_slist_length(data->contacts),
- data->newmissedcalls, lastpart, data->user_data);
-
+ amount = g_slist_length(data->contacts);
free_data_contacts(data);
+
+ data->cb(vcards->str, vcards->len, amount, data->newmissedcalls,
+ lastpart, data->user_data);
+
g_string_free(vcards, TRUE);
}

--
1.7.0.4

2011-03-11 15:46:03

by Radoslaw Jablonski

Subject: Re: [PATCH] Change order of freeing contacts data in send_pull_part

Hi,

On 03/11/2011 12:24 PM, Radoslaw Jablonski wrote:
> Moved freeing data->contacts before asynchronous data sending
> is triggered via data->cb callback.
> This data is no longer needed anyway after vcards are generated
> and freeing it later may cause race condition (because freeing
> this data need to be handled also in phonebook_req_finalize to
> avoid memory leaks when client disconnects in the middle of
> retrieving contacts from db).
> ---
> plugins/phonebook-tracker.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
Please ignore this patch - these changes are not needed in
current architecture (based on offline discussion with Johan).

BR,
Radek