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