----- Original Message -----
> From: Hans-Christoph Steiner <h...@at.or.at>
> To: Jonathan Wilkes <jancs...@yahoo.com>; Krzysztof Czaja
> <cz...@chopin.edu.pl>; pd-dev <pd-dev@iem.at>
> Cc: Ivica Ico Bukvic <i...@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 <cz...@chopin.edu.pl>
>> > To: pd-dev <pd-dev@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@iem.at
>> > http://lists.puredata.info/listinfo/pd-dev
>> >
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev@iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
>
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev