This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] PR gdb/17210 - fix possible memory leak in read_memory_robust
- From: Tom Tromey <tom at tromey dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Tom Tromey <tom at tromey dot com>, "gdb-patches\ at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 28 Jun 2016 08:39:45 -0600
- Subject: Re: [RFA] PR gdb/17210 - fix possible memory leak in read_memory_robust
- Authentication-results: sourceware.org; auth=none
- References: <1465490013-15336-1-git-send-email-tom at tromey dot com> <CAH=s-PMjZN9byLwAGs+yQjEhDzMJEe0RxGuT-tg89+DFxgk6ew at mail dot gmail dot com>
>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:
Yao> On Thu, Jun 9, 2016 at 5:33 PM, Tom Tromey <tom@tromey.com> wrote:
>>
>> VEC(memory_read_result_s) *
>> @@ -1810,6 +1810,8 @@ read_memory_robust (struct target_ops *ops,
>> {
>> VEC(memory_read_result_s) *result = 0;
>> int unit_size = gdbarch_addressable_memory_unit_size (target_gdbarch ());
>> + struct cleanup *cleanup = make_cleanup (free_memory_read_result_vector,
>> + &result);
>>
Yao> result is a local variable on stack, so its address is meaningless when the
Yao> exception is throw, because the stack has already been destroyed.
Yao> Probably, we can register cleanup for result once it becomes to non-NULL,
Yao> and changes in free_memory_read_result_vector are not needed.
I don't think that will work, because resizing the vector may cause the
value to change. Though one option would be to discard the cleanup and
recreate it after each push.
Tom