[PD-dev] potential memory leak in g_graph.c

Miller Puckette msp at ucsd.edu
Tue Feb 26 05:17:45 CET 2013


I don't remember why it's there (and perhaps it's no longer necessary) -
but I suspect it had something to do with a subtle problem when deleting
a GOP whose interior got mad wieh there was no rtext for the owning object.

The rtext eventualy goes away when the window is closed - but perhaps it's
a problem if there's a self-editing patch that creates and deletes
1000s of objects in an open window?

cheers
Miller


On Mon, Feb 25, 2013 at 10:36:46PM -0500, Ivica Ico Bukvic wrote:
> Does anyone know why does the following exist inside the
> glist_delete function inside g_graph.c:
> 
>             /* if we're a drawing command, erase all scalars now,
> before deleting
>             it; we'll redraw them once it's deleted below. */
>         if (drawcommand)
> canvas_redrawallfortemplate(template_findbyname(canvas_makebindsym(
>                 glist_getcanvas(x)->gl_name)), 2);
>         if (glist_isvisible(canvas))
>             gobj_vis(y, x, 0);
>   -->      if (x->gl_editor && (ob = pd_checkobject(&y->g_pd)))
>   -->          rtext_new(x, ob);
>         if (x->gl_list == y) {
> 
> That rtext is never freed after that so unless I am missing
> something I see no reason why we would want to do this. Any ideas?
> 
> -- 
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Head, ICAT IMPACT Studio
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
> 

> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev




More information about the Pd-dev mailing list