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.
.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@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
>