Merged revisions 346349 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/10

........
  r346349 | dvossel | 2011-11-28 18:00:11 -0600 (Mon, 28 Nov 2011) | 10 lines
  
  Fixes memory leak in message API.
  
  The ast_msg_get_var function did not properly decrement
  the ref count of the var it retrieves.  The way this is
  implemented is a bit tricky, as we must decrement the var and then
  return the var's value.  As long as the documentation for the
  function is followed, this will not result in a dangling pointer as
  the ast_msg structure owns its own reference to the var while it
  exists in the var container.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346350 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 9 insertions, 1 deletions

diff --git a/main/message.c b/main/message.c
index f2c5f4ddb..edc54c8ea 100644
--- a/main/message.c
+++ b/main/message.c
@@ -522,12 +522,20 @@ int ast_msg_set_var(struct ast_msg *msg, const char *name, const char *value)
 const char *ast_msg_get_var(struct ast_msg *msg, const char *name)
 {
 	struct msg_data *data;
+	const char *val = NULL;
 
 	if (!(data = msg_data_find(msg->vars, name))) {
 		return NULL;
 	}
 
-	return data->value;
+	/* Yep, this definitely looks like val would be a dangling pointer
+	 * after the ref count is decremented.  As long as the message structure
+	 * is used in a thread safe manner, this will not be the case though.
+	 * The ast_msg holds a reference to this object in the msg->vars container. */
+	val = data->value;
+	ao2_ref(data, -1);
+
+	return val;
 }
 
 struct ast_msg_var_iterator {