[PD-dev] deadly leak

[Miller Puckette]

Personally, I'm hoping to put band-aids on as many manaifestations of the
problem as I can track down (so thanks for this one :)  and then re-design
the whole editor creation and destruction strategy for 0.44 - it looks
like it can never be fully debugged the way it's stet up now!

Miller

On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote:
> On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote:
> ...
> >Wow! You just helped me finally solve this riddle! Could it be really
> >this simple? In canvas_free() call inside g_canvas.c simply add the
> >following 2 lines:
> >
> >	if (x->gl_editor)
> >		canvas_destroy_editor(x);
> >
> >I added them right below
> >
> >     if (x == glist_getcanvas(x))
> >         canvas_vis(x, 0);
> >
> >Now even if the canvas is recreated with the same memory space there is
> >no more double-entry bug. Are there any potential regressions with this
> >model? The canvas is getting freed so I cannot imagine this posing any
> >problems but then again I am sure I may be missing something...
> 
> this only handles the case when the GOP is part of a toplevel window.
> 
> The other case is when the GOP's parent isn't toplevel.  When the
> window of such a parent is closed, the canvases themselves aren't
> destroyed, but the editors should be.
> 
> So I think the best way is to get rid of sub-editors recursively.
> I may be mistaken, though, because there are some partial workarounds
> already in the code.  Apparently, Miller had been aware of the issue
> but then things went their own way, somehow.
> 
> Krzysztof
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev