On 06/05/2012 04:01 PM, Kenneth Graunke wrote:
While ~loop_state() is already freeing the loop_variable_state objects via ralloc_free(this->mem_ctx), the ~loop_variable_state() destructor was never getting called, so the hash table inside loop_variable_state was never getting destroyed.Fixes a memory leak in any shader with loops. NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke<kenn...@whitecape.org> --- src/glsl/loop_analysis.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h index 8bed1db..05c982f 100644 --- a/src/glsl/loop_analysis.h +++ b/src/glsl/loop_analysis.h @@ -140,6 +140,23 @@ public: { hash_table_dtor(this->var_hash); } + + static void* operator new(size_t size, void *ctx) + { + void *lvs = ralloc_size(ctx, size); + assert(lvs != NULL); + + ralloc_set_destructor(lvs, (void (*)(void*)) destructor); + + return lvs; + } + +private: + static void + destructor(loop_variable_state *lvs) + { + lvs->~loop_variable_state(); + } };
This just looks wrong. :) Would it be better to have the real destructor code here and ~loop_variable_state call this->destructor?
In my dream of dreams, we'd be able to either allocate objects via ralloc or allocate (automatic) objects on the stack.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
