3:37 a.m.
Please find changes in mmsd in order to fix problems that occurred when
unregistering messages.
1) the messages table contains mms_message object and not uuid, now
every message is unregister with its correct path when the messages
table is destroyed. Furthermore, don't need to remove the message from
the table using g_hash_table_foreach_remove() since
mms_message_unregister() already removed it from the table.
2) use the msg_path (within the debug statement) before removing the
message from the table which free it
Ronald Tessier (2):
service: fix object path when unregistering msg
service: free the msg after tracing its path
src/service.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
--
1.7.4.1
3:37 a.m.
New subject: [PATCH 1/2] service: fix object path when unregistering msg
The 'value' parameter is an mms_message pointer and not a pointer to
the uuid.
Don't need to remove message from the hash table (with
g_hash_table_foreach_remove) since calling mms_message_unregister()
on every messages will remove them from the hash table.
---
src/service.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/service.c b/src/service.c
index ef6b544..fc69e0d 100644
--- a/src/service.c
+++ b/src/service.c
@@ -875,15 +875,12 @@ struct mms_service *mms_service_ref(struct mms_service *service)
return service;
}
-static gboolean unregister_message(gpointer key, gpointer value,
- gpointer user_data)
+static void unregister_message(gpointer key, gpointer value, gpointer user_data)
{
struct mms_service *service = user_data;
- char *uuid = value;
+ struct mms_message *msg = value;
- mms_message_unregister(service, uuid);
-
- return TRUE;
+ mms_message_unregister(service, msg->path);
}
static void destroy_message_table(struct mms_service *service)
@@ -897,8 +894,7 @@ static void destroy_message_table(struct mms_service *service)
* This step is required because we need access to mms_service when
* unregistering the message object.
*/
- g_hash_table_foreach_remove(service->messages, unregister_message,
- service);
+ g_hash_table_foreach(service->messages, unregister_message, service);
g_hash_table_destroy(service->messages);
service->messages = NULL;
--
1.7.4.1
3:37 a.m.
New subject: [PATCH 2/2] service: free the msg after tracing its path
Move debug statement before freeing the message so the message path is
reliable
---
src/service.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/service.c b/src/service.c
index fc69e0d..4ad9d39 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1607,10 +1607,10 @@ int mms_message_unregister(const struct mms_service *service,
return -EIO;
}
- g_hash_table_remove(service->messages, msg_path);
-
DBG("message unregistered %s", msg_path);
+ g_hash_table_remove(service->messages, msg_path);
+
return 0;
}
--
1.7.4.1
3:37 a.m.
New subject: [PATCH 0/1] mmsd service
This patch concerns mmsd.
Ronald Tessier (1):
service: remove unused mms_request's members
src/service.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
--
1.7.4.1
3:37 a.m.
New subject: [PATCH 1/1] service: remove unused mms_request's members
---
src/service.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/service.c b/src/service.c
index 4ad9d39..14b5284 100644
--- a/src/service.c
+++ b/src/service.c
@@ -96,8 +96,6 @@ struct mms_request {
char *data_path;
char *location;
gsize data_size;
- gpointer data;
- gsize offset;
int fd;
guint16 status;
struct mms_service *service;
--
1.7.4.1
7:23 a.m.
Hi Ronald,
Please find changes in mmsd in order to fix problems that occurred
when
unregistering messages.
1) the messages table contains mms_message object and not uuid, now
every message is unregister with its correct path when the messages
table is destroyed. Furthermore, don't need to remove the message from
the table using g_hash_table_foreach_remove() since
mms_message_unregister() already removed it from the table.
2) use the msg_path (within the debug statement) before removing the
message from the table which free it
both patches have been applied.
Regards
Marcel
3832
days inactive
3832
days old
6 comments
2 participants
participants (2)
-
Marcel Holtmann -
Ronald Tessier