[Mesa-dev] [PATCH] glsl: fix loop_variable_state->var_hash leak
Kenneth Graunke
kenneth at whitecape.org
Wed Jun 6 00:58:20 CEST 2012
On 06/05/2012 02:49 PM, Marcin Slusarz wrote:
>
> ---
> src/glsl/loop_analysis.cpp | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
> index 6a0e4da..6548e15 100644
> --- a/src/glsl/loop_analysis.cpp
> +++ b/src/glsl/loop_analysis.cpp
> @@ -42,8 +42,14 @@ loop_state::loop_state()
> }
>
>
> +static void destroy_loop_var_state(const void *key, void *data, void *closure)
> +{
> + delete (loop_variable_state *)data;
> +}
> +
> loop_state::~loop_state()
> {
> + hash_table_call_foreach(this->ht, destroy_loop_var_state, NULL);
> hash_table_dtor(this->ht);
> ralloc_free(this->mem_ctx);
> }
This makes me nervous. They're allocated via ralloc:
loop_variable_state *ls = new(this->mem_ctx) loop_variable_state;
which internally uses malloc/calloc and friends, not new/delete.
~loop_state() already calls ralloc_free(this->mem_ctx), which frees all
the loop_variable_state objects. However, the loop_variable_state
destructor isn't hooked up, so hash_table_dtor(this->var_hash) is never
getting called.
I'll reply in a moment with a patch to use ralloc invoke the destructor.
It may be possible to rework ralloc such that C++ destructors just work.
I'll have to think about that.
More information about the mesa-dev
mailing list