[PD-dev] deadly leak

[Hans-Christoph Steiner]

There are a couple of minor details in that patch that I fixed in the attached patch:

- remove debugging post() messages from editor_new() and editor_free()

- remove glist_free() and glist_cleanup() from g_canvas.h since they no longer exist

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fixes-for-workaround-for-gop-multiplicity-bug-262193.patch
Type: application/octet-stream
Size: 1383 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20111215/bc6d39a6/attachment.obj>
-------------- next part --------------

On Dec 14, 2011, at 8:02 PM, Miller Puckette wrote:

> 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
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



----------------------------------------------------------------------------

News is what people want to keep hidden and everything else is publicity.          - Bill Moyers