[PATCH] varobj.c, value_of_root, (another) memory leak

[PATCH] varobj.c, value_of_root, (another) memory leak

[msnyder]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

I'm not totally sure about this -- does the return value of var_get_type
need to be freed?  If so, there are some other places in mi-cmd-var
where it isn't being.


[-- Attachment #2: 147.txt --]
[-- Type: text/plain, Size: 580 bytes --]

2007-08-10  Michael Snyder  <msnyder@access-company.com>

	* varobj.c (value_of_root): Memory leak.

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.90
diff -p -r1.90 varobj.c
*** varobj.c	8 Aug 2007 21:46:37 -0000	1.90
--- varobj.c	10 Aug 2007 22:58:51 -0000
*************** value_of_root (struct varobj **var_handl
*** 1741,1746 ****
--- 1741,1748 ----
  	  var = *var_handle;
  	  *type_changed = 1;
  	}
+       xfree (old_type);
+       xfree (new_type);
      }
    else
      {

Re: [PATCH] varobj.c, value_of_root, (another) memory leak

[Nick Roberts]

 > I'm not totally sure about this -- does the return value of var_get_type
 > need to be freed?  If so, there are some other places in mi-cmd-var
 > where it isn't being.

Yes, I think this is right but USE_SELECTED_FRAME is broken anyway.  The
ones in mi-cmd-var.c may be more important.  Similar problems seem to
occur with varobj_get_expression and varobj_get_value. Since the expression
associated with a variable object doesn't change, I think c_name_of_variable
could just be:

static char *
c_name_of_variable (struct varobj *var)
{
  return var->name;
}

Are we close to release or branchpoint?  If not let's do these things now.
I also have a patch for editable/changeable properties of variable ojects
which I'd like to resubmit for approval if a release is no longer imminent.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


 > 2007-08-10  Michael Snyder  <msnyder@access-company.com>
 > 
 > 	* varobj.c (value_of_root): Memory leak.
 > 
 > Index: varobj.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/varobj.c,v
 > retrieving revision 1.90
 > diff -p -r1.90 varobj.c
 > *** varobj.c	8 Aug 2007 21:46:37 -0000	1.90
 > --- varobj.c	10 Aug 2007 22:58:51 -0000
 > *************** value_of_root (struct varobj **var_handl
 > *** 1741,1746 ****
 > --- 1741,1748 ----
 >   	  var = *var_handle;
 >   	  *type_changed = 1;
 >   	}
 > +       xfree (old_type);
 > +       xfree (new_type);
 >       }
 >     else
 >       {

Re: [PATCH] varobj.c, value_of_root, (another) memory leak

[Daniel Jacobowitz]

On Sat, Aug 11, 2007 at 01:40:33PM +1200, Nick Roberts wrote:
> Are we close to release or branchpoint?

I hope that we branch the moment we have decided how to handle GPLv3.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] varobj.c, value_of_root, (another) memory leak

[msnyder]

> On Sat, Aug 11, 2007 at 01:40:33PM +1200, Nick Roberts wrote:
>> Are we close to release or branchpoint?
>
> I hope that we branch the moment we have decided how to handle GPLv3.

Shall I hold back this patch then ?

Re: [PATCH] varobj.c, value_of_root, (another) memory leak

[msnyder]

>  > I'm not totally sure about this -- does the return value of
> var_get_type
>  > need to be freed?  If so, there are some other places in mi-cmd-var
>  > where it isn't being.
>
> Yes, I think this is right but USE_SELECTED_FRAME is broken anyway.  The
> ones in mi-cmd-var.c may be more important.  Similar problems seem to
> occur with varobj_get_expression and varobj_get_value.

Committed.