<html><head></head><body>This problem has a series of fixes spread all across the code. It is not one instance but literally dozens. Just when I thought I had them all I found one last lingering one just a couple of weeks ago. That said I think pd-l2ork's implementation is now rock solid with all its redraw issues and quirks fixed.<br>
<br>
Coming soon, infinite undo :-). I already have half of the undo actions implemented, including a number that are entirely missing in vanilla, but there are still some fundamental changes that need to take place so I'm hoping to finish it by the end of the week. If you're curious about the latest dev snapshot knowing that it is currently unstable, try checking out the pd-l2ork from the git repository. For a stable (albeit older) version you can always visit the L2Ork website.<br>
<br>
Cheers!<br>
<br>
Ivica Ico Bukvic, D.M.A<br>
Composition, Music Technology<br>
Director, DISIS Interactive Sound & Intermedia Studio<br>
Director, L2Ork Linux Laptop Orchestra<br>
Assistant Director, CCTAD<br>
Virginia Tech<br>
Department of Music<br>
Blacksburg, VA 24061-0240<br>
(540) 231-6139<br>
(540) 231-5034 (fax)<br>
<a href="http://disis.music.vt.edu">disis.music.vt.edu</a><br>
<a href="http://l2ork.music.vt.edu">l2ork.music.vt.edu</a><br>
<a href="http://ico.bukvic.net">ico.bukvic.net</a><br><br><div class="gmail_quote">Hans-Christoph Steiner <hans@at.or.at> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif"><br />Hey Krzysztof,<br /><br />Glad to see you posting again on pd-dev! :) Thanks for the breakdown<br />on the bug, that should be helpful, especially combined with pd-l2ork. <br />Jonathan, do you know which release date introduced this fix in<br />pd-l2ork? Then we can isolate it. Otherwise its difficult to navigate<br />the pd-l2ork commit history.<br /><br />.hc<br /><br /><br />On Mon, Dec 12, 2011, at 17:40, Jonathan Wilkes wrote:<br />> HiKrzysztof,<br />> I believe Ivica fixed this bug in Pd-l2ork back in March. From <a href="http://l2ork.music.vt.edu/data/pd/Changelog">http://l2ork.music.vt.edu/data/pd/Changelog</a>:<br />> *fixed problem where doubly-nested gops still caused double-entry bug<br />> after cut/undo inside the abstraction.<br />> <br />> <br />> I haven't run into the double-entry problem in Pd-l2ork since then, but I<br />> can confirm
it's still a problem in 0.43.<br />> <br />> -Jonathan<br />> <br />> <br />> ----- Original Message -----<br />> > From: Krzysztof Czaja <czaja@chopin.edu.pl><br />> > To: pd-dev <pd-dev@iem.at><br />> > Cc: <br />> > Sent: Monday, December 12, 2011 8:15 PM<br />> > Subject: [PD-dev] deadly leak<br />> > <br />> > Hi Pd gurus,<br />> > <br />> > ever found a single keystroke or a mouse click was duplicated<br />> > on a patch? A strange bug which always turns out to be fatal<br />> > at the point of closing the patch?<br />> > <br />> > Hit by several such crashes one after another I went hunting.<br />> > <br />> > What I found was that there is always a t_editor created for<br />> > a GOP graph. The constructor is invoked by the first<br />> > glist_findrtext() call aimed at anything inside of that GOP<br />> > (this occurs when the parent is
being mapped).<br />> > <br />> > Thus, the editor_new() for a GOP is called, but the<br />> > corresponding editor_free() seems never to be called.<br />> > <br />> > The reason why this is not an innocent leak, but a crasher<br />> > is quite subtle.<br />> > <br />> > For any t_editor, there is a t_guiconnect object created and<br />> > bound to a symbol made up from the address of the editor's<br />> > owner (a glist). Since the editor is zombiefied, so is the<br />> > guiconnect, and the symbol is never unbound.<br />> > <br />> > The trouble begins when another canvas is allocated at the<br />> > address freed by the late owner of the zombie. The editor is<br />> > created, and a new t_guiconnect is bound to the old symbol.<br />> > <br />> > Now, if any message is sent to the symbol, it is caught by<br />> > two t_guiconnect objects, both pointing to the same
address:<br />> > their 'x_who' pointer. Hence, all messages from pd-gui to<br />> > the new canvas are duplicated. The agony is terminated by<br />> > the second copy of the message 'menuclose'.<br />> > <br />> > I believe this bug has never been dealt with. So, in case<br />> > you consider it worthwhile, could someone forgive me my<br />> > slothfulness and file this thing into the <a href="http://sf.net">sf.net</a> bug tracker<br />> > or open a github's issue, whichever is more appropriate<br />> > these days.<br />> > <br />> > Krzysztof<br />> > <br />> ><hr /><br />> > Pd-dev mailing list<br />> > Pd-dev@iem.at<br />> > <a href="http://lists.puredata.info/listinfo/pd-dev">http://lists.puredata.info/listinfo/pd-dev</a><br />> > <br />> <br />><hr /><br />> Pd-dev mailing list<br />> Pd-dev@iem.at<br />> <a
href="http://lists.puredata.info/listinfo/pd-dev">http://lists.puredata.info/listinfo/pd-dev</a><br />> <br /></pre></blockquote></div></body></html>