[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