[PD-dev] deadly leak

[Ivica Ico Bukvic]

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