This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] fixing leaking struct value* in py-value.c
- From: Tom Tromey <tromey at redhat dot com>
- To: Aman Gupta <themastermind1 at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 12 Nov 2010 13:10:22 -0700
- Subject: Re: [patch] fixing leaking struct value* in py-value.c
- References: <AANLkTi=aTzykNv6HR-D+vK5CJ295w0xC21tY-KEnxw+q@mail.gmail.com>
>>>>> "Aman" == Aman Gupta <themastermind1@gmail.com> writes:
Aman> The gdb process will leak a large amount of memory (>512mb RSS) while
Aman> executing the python loop. Some (but not all) of this memory is
Aman> returned after the loop completes and free_all_values() is called for
Aman> the next command. The following patch against gdb master
Aman> keeps the memory usage constant during the loop.
Thanks for writing this. It looks reasonable overall.
Do you have a gdb copyright assignment in place? I can't check, and we
will need one to accept this patch. If you do not have one, email me
and I will get you started on the process.
Aman> @@ -1062,7 +1081,7 @@ value_to_value_object (struct value *val)
[...]
Aman> - value_incref (val);
Aman> + release_value_or_incref (val);
I'm not sure that this is always ok. I think it depends on the other
callers of release_value, at least. (There is also some code in gdb
that inspects the value chain, but I think that code can't really
interact with this code.)
A different approach would be to have a wrapper for
value_to_value_object that calls release_value. Then, we could use this
wrapper whenever we know it is safe -- when the value in question was
created during some computation in the Python layer.
What do you think?
Aman> +int
Aman> release_value (struct value *val)
[...]
Aman> + return -1;
It is more idiomatic to "return 1" here.
Tom