Pre-existing bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=2621932&group_id=55736&atid=478070
I can confirm it still causes multiplicity in Pd-0.43. I'll try the newest Pd-l2ork version in a bit to see whether it affects that one. -Jonathan ----- Original Message ----- > From: Jonathan Wilkes <jancs...@yahoo.com> > To: Krzysztof Czaja <cz...@chopin.edu.pl>; pd-dev <pd-dev@iem.at> > Cc: Ivica Ico Bukvic <i...@vt.edu> > Sent: Monday, December 12, 2011 8:40 PM > Subject: Re: [PD-dev] deadly leak > > 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