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

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.

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.

Cheers!

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

Hans-Christoph Steiner hans@at.or.at wrote:

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

OK,

So, I reenabled the workaround I had used before in pd-l2ork and all is well again. But it still does use a workaround and an ugly one at that. Yet, that is the *only* way I can see fixing this. The problem is essentially what I had mentioned already cutting and undoing cutting a canvas object (embedded or abstraction) at times gives the new object the same address and this results in multiple entry bug. The more times it gives it this address on subsequent cut/undo, the more multiple entries you get per entry. What is known:

*Pd_unbind always takes place as the per current code. I do not know this part of the code well enough to say it works as it should but it seems to. There is one aspect (s->s_thing) that never asks, it's just set to 0 or back to the s->s_thing, but like I said I am not familiar enough with this aspect of the code.

*This is not a Tcl/Tk problem since it always issues a single command to C, and even C issues single command, yet it is registered multiple times.

*I agree with Mathieu that this is something having to do with unbinding of keyboard/mouse commands to an address space but I have no idea where this is (*any ideas?*)

So, the only way I can ensure in pd-l2ork that this never happens is that I enable global variable in canvas_new making sure that pd_new function is aware its next allocation is for a canvas. I also maintain a global single-linked list of previously allocated memory locations of canvases and check that the newly created canvas does not reuse old memory location. If it does, its size is reduced to 1 and a new one is instantiated at at least 1 byte offset (due to the one reduced to size 1), after which the old (the one with the size of 1 byte) is deallocated. Then the new one is checked and so on until the canvas is assigned a non-duplicate location. Then the new successful location is added to the global single list to check against future occurrences. It's ugly but it works and does not affect the runtime side of things since this only happens when creating canvases (unless you are live-coding canvases, I guess). I tried to monitor how many duplicates are being created and the best case scenario is 1 worst is 8 on an abstraction that has 9+ canvases inside it (l2ork_output~ found in the l2ork abstractions, if you are curious).

I committed this to the pd-l2ork git as a separate commit in hope it will help others study the problem. Please bear in mind this code has been in pd-l2ork all along so the said commit only uncomments a few things and improves upon some of the aspects.

So, at this point my key question is:

Where does the binding of keyboard/mouse commands to a specific memory location occur? Is this a leftover of bound commands in wm manager?

Any thoughts?

Best wishes,

Ico

Mathieu Bouchard matju@artengine.ca wrote:

Le 2011-12-14 à 10:15:00, Ivica Ico Bukvic a écrit :

...

So, the only way I can ensure in pd-l2ork that this never happens is that I enable global variable in canvas_new making sure that pd_new function is aware its next allocation is for a canvas. I also

maintain a

...

global single-linked list of previously allocated memory locations of

...

canvases and check that the newly created canvas does not reuse old memory location.

In DesireData, I had a concept called «zombies» that was quite similar to that. It would postpone deallocation of objects until it knew that the client (tcl/tk) would not confuse the dead object with the newer object. During that time, the object is destructed (the freemethod was called) but freebytes isn't called yet, and the class of the object is changed to ensure that every message received is reported as an error and doesn't crash.

But it doesn't look like the duplicate messages are at all related to that kind of problem/solution. It looks like just a bug of forgetting to call pd_unbind in one place. Any such bug that also exists in pd-vanilla is unrelated to zombie-style solutions, as far as I can think of the problem.

So what part of the code specifically binds keyboard and mouse actions to a canvas? I thought this was never explicitly bound but is rather a result of tcl/tk simply reporting events within a specific canvas whose name was given to it by its memory allocation. Otherwise, which pd_bind does that?

FWIW canvas_free calls pd_unbind and it does indeed unbind things, although without knowing where the original bind relevant to this problem occurs, I have no way of telling wehether those unbinds have anything to do with it.

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net