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