[PD-dev] deadly leak

[Jonathan Wilkes]

----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>; Krzysztof Czaja <czaja at chopin.edu.pl>; pd-dev <pd-dev at iem.at>
> Cc: Ivica Ico Bukvic <ico at vt.edu>
> Sent: Monday, December 12, 2011 9:40 PM
> Subject: Re: [PD-dev] deadly leak
> 
> 
> Hey Krzysztof,
> 
> Glad to see you posting again on pd-dev!  :)  Thanks for the breakdown
> on the bug, that should be helpful, especially combined with pd-l2ork. 
> Jonathan, do you know which release date introduced this fix in
> pd-l2ork?  Then we can isolate it.  Otherwise its difficult to navigate
> the pd-l2ork commit history.

The comment in the changelog I referenced below was from 2011-03-26.

In 2011-04-03 there's this:
*removed some of the workarounds for the aforesaid double-entry bug which proved to be fixes for the symptoms rather than the core problem    

Then in 2011-04-11:
*finally discovered the root of all double-entry bugs (fingers crossed) and reverted all other previous workarounds for this problem.

That's the last entry in the changelog I see that is related to this issue, but I only tested my crasher patch on 2011-12-09 to confirm that the crash or double-entry is indeed gone in this case with Pd-l2ork.

-Jonathan

> 
> .hc
> 
> 
> On Mon, Dec 12, 2011, at 17:40, Jonathan Wilkes wrote:
    >>  HiKrzysztof,
>>       I believe Ivica fixed this bug in Pd-l2ork back in March.  From 
> http://l2ork.music.vt.edu/data/pd/Changelog:
>>  *fixed problem where doubly-nested gops still caused double-entry bug
>>  after cut/undo inside the abstraction.
>> 
>> 
>>  I haven't run into the double-entry problem in Pd-l2ork since then, but 
> I
>>  can confirm it's still a problem in 0.43.
>> 
>>  -Jonathan
>> 
>> 
>>  ----- Original Message -----
>>  > From: Krzysztof Czaja <czaja at chopin.edu.pl>
>>  > To: pd-dev <pd-dev at iem.at>
>>  > Cc: 
>>  > Sent: Monday, December 12, 2011 8:15 PM
>>  > Subject: [PD-dev] deadly leak
>>  > 
>>  > Hi Pd gurus,
>>  > 
>>  > ever found a single keystroke or a mouse click was duplicated
>>  > on a patch?  A strange bug which always turns out to be fatal
>>  > at the point of closing the patch?
>>  > 
>>  > Hit by several such crashes one after another I went hunting.
>>  > 
>>  > What I found was that there is always a t_editor created for
>>  > a GOP graph.  The constructor is invoked by the first
>>  > glist_findrtext() call aimed at anything inside of that GOP
>>  > (this occurs when the parent is being mapped).
>>  > 
>>  > Thus, the editor_new() for a GOP is called, but the
>>  > corresponding editor_free() seems never to be called.
>>  > 
>>  > The reason why this is not an innocent leak, but a crasher
>>  > is quite subtle.
>>  > 
>>  > For any t_editor, there is a t_guiconnect object created and
>>  > bound to a symbol made up from the address of the editor's
>>  > owner (a glist).  Since the editor is zombiefied, so is the
>>  > guiconnect, and the symbol is never unbound.
>>  > 
>>  > The trouble begins when another canvas is allocated at the
>>  > address freed by the late owner of the zombie.  The editor is
>>  > created, and a new t_guiconnect is bound to the old symbol.
>>  > 
>>  > Now, if any message is sent to the symbol, it is caught by
>>  > two t_guiconnect objects, both pointing to the same address:
>>  > their 'x_who' pointer.  Hence, all messages from pd-gui to
>>  > the new canvas are duplicated.  The agony is terminated by
>>  > the second copy of the message 'menuclose'.
>>  > 
>>  > I believe this bug has never been dealt with.  So, in case
>>  > you consider it worthwhile, could someone forgive me my
>>  > slothfulness and file this thing into the sf.net bug tracker
>>  > or open a github's issue, whichever is more appropriate
>>  > these days.
>>  > 
>>  > 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
>> 
>