Re: [PATCH v2 28/31] Use ui_file_as_string throughout more

Yao Qi
2017-02-23T10:35:55Z

Pedro Alves <palves@redhat.com> writes:

> diff --git a/gdb/python/py-varobj.c b/gdb/python/py-varobj.c
> index 7e74454..a6b1968 100644
> --- a/gdb/python/py-varobj.c
> +++ b/gdb/python/py-varobj.c
> @@ -113,11 +113,11 @@ py_varobj_iter_next (struct varobj_iter *self)
> error (_("Invalid item from the child list"));
> }
>
> - vitem = XNEW (struct varobj_item);
> + vitem = new varobj_item ();
> vitem->value = convert_value_from_python (py_v);
> if (vitem->value == NULL)
> gdbpy_print_stack ();

We started to use new but still use xfree somewhere in the code. This
patches change xfree to delete. Patch below is obvious. I'll push it
in.

--
Yao (齐尧)
From 8b4e5d54c9fee2b1d890a9937696297b5cd7ef5c Mon Sep 17 00:00:00 2001
From: Yao Qi <yao.qi@linaro.org>
Date: Thu, 23 Feb 2017 10:28:44 +0000
Subject: [PATCH] Use delete instead of xfree for varobj_item

In commit 2f408ec (Use ui_file_as_string throughout more), we start to
new varobj_item,

> - vitem = XNEW (struct varobj_item);
> + vitem = new varobj_item ();

but we still use xfree. This causes some ASAN errors,

-var-update container^M
=================================================================^M
^[[1m^[[31m==20660==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new vs free) on 0x602000090c10^M
^[[1m^[[0m #0 0x2baa77d03631 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54631)^M
#1 0x80e0c8 in xfree(void*) /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:100^M
#2 0xc13670 in varobj_clear_saved_item /home/yao/SourceCode/gnu/gdb/git/gdb/varobj.c:727^M
#3 0xc13957 in update_dynamic_varobj_children /home/yao/SourceCode/gnu/gdb/git/gdb/varobj.c:752^M
#4 0xc1841c in varobj_update(varobj**, int) /home/yao/SourceCode/gnu/gdb/git/gdb/varobj.c:1699^M
#5 0x5a2bf7 in varobj_update_one /home/yao/SourceCode/gnu/gdb/git/gdb/mi/mi-cmd-var.c:712^M
#6 0x5a2a41 in mi_cmd_var_update(char*, char**, int) /home/yao/SourceCode/gnu/gdb/git/gdb/mi/mi-cmd-var.c:695^
........
^M
^[[1m^[[32m0x602000090c10 is located 0 bytes inside of 16-byte region [0x602000090c10,0x602000090c20)^M
^[[1m^[[0m^[[1m^[[35mallocated by thread T0 here:^[[1m^[[0m^M
#0 0x2baa77d0415f in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5515f)^M
#1 0x63613e in py_varobj_iter_next /home/yao/SourceCode/gnu/gdb/git/gdb/python/py-varobj.c:112^M
#2 0xc13b89 in update_dynamic_varobj_children /home/yao/SourceCode/gnu/gdb/git/gdb/varobj.c:776^M
#3 0xc1841c in varobj_update(varobj**, int) /home/yao/SourceCode/gnu/gdb/git/gdb/varobj.c:1699^M
#4 0x5a2bf7 in varobj_update_one /home/yao/SourceCode/gnu/gdb/git/gdb/mi/mi-cmd-var.c:712^M
#5 0x5a2a41 in mi_cmd_var_update(char*, char**, int) /home/yao/SourceCode/gnu/gdb/git/gdb/mi/mi-cmd-var.c:695^M

gdb:

2017-02-23 Yao Qi <yao.qi@linaro.org>

* varobj.c (varobj_clear_saved_item): Use delete instead of
xfree.
(update_dynamic_varobj_children): Likewise.

diff --git a/gdb/varobj.c b/gdb/varobj.c
index 4b12826..173abf3 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -724,7 +724,7 @@ varobj_clear_saved_item (struct varobj_dynamic *var)
if (var->saved_item != NULL)
{
value_free (var->saved_item->value);
- xfree (var->saved_item);
+ delete var->saved_item;
var->saved_item = NULL;
}
}
@@ -799,7 +799,7 @@ update_dynamic_varobj_children (struct varobj *var,
can_mention ? cchanged : NULL, i,
item);

- xfree (item);
+ delete item;
}
else
{