Re: [PD-dev] deadly leak
There are a couple of minor details in that patch that I fixed in the attached patch: - remove debugging post() messages from editor_new() and editor_free() - remove glist_free() and glist_cleanup() from g_canvas.h since they no longer exist .hc 0001-fixes-for-workaround-for-gop-multiplicity-bug-262193.patch Description: Binary data On Dec 14, 2011, at 8:02 PM, Miller Puckette wrote: > Personally, I'm hoping to put band-aids on as many manaifestations of the > problem as I can track down (so thanks for this one :) and then re-design > the whole editor creation and destruction strategy for 0.44 - it looks > like it can never be fully debugged the way it's stet up now! > > Miller > > On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote: >> On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: >> ... >>> Wow! You just helped me finally solve this riddle! Could it be really >>> this simple? In canvas_free() call inside g_canvas.c simply add the >>> following 2 lines: >>> >>> if (x->gl_editor) >>> canvas_destroy_editor(x); >>> >>> I added them right below >>> >>>if (x == glist_getcanvas(x)) >>>canvas_vis(x, 0); >>> >>> Now even if the canvas is recreated with the same memory space there is >>> no more double-entry bug. Are there any potential regressions with this >>> model? The canvas is getting freed so I cannot imagine this posing any >>> problems but then again I am sure I may be missing something... >> >> this only handles the case when the GOP is part of a toplevel window. >> >> The other case is when the GOP's parent isn't toplevel. When the >> window of such a parent is closed, the canvases themselves aren't >> destroyed, but the editors should be. >> >> So I think the best way is to get rid of sub-editors recursively. >> I may be mistaken, though, because there are some partial workarounds >> already in the code. Apparently, Miller had been aware of the issue >> but then things went their own way, somehow. >> >> 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 News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Sounds like a good plan. I think a number of us support that goal. Any specific way we can help in the near future to get the ball rolling on that? .hc On Dec 14, 2011, at 8:02 PM, Miller Puckette wrote: > Personally, I'm hoping to put band-aids on as many manaifestations of the > problem as I can track down (so thanks for this one :) and then re-design > the whole editor creation and destruction strategy for 0.44 - it looks > like it can never be fully debugged the way it's stet up now! > > Miller > > On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote: >> On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: >> ... >>> Wow! You just helped me finally solve this riddle! Could it be really >>> this simple? In canvas_free() call inside g_canvas.c simply add the >>> following 2 lines: >>> >>> if (x->gl_editor) >>> canvas_destroy_editor(x); >>> >>> I added them right below >>> >>>if (x == glist_getcanvas(x)) >>>canvas_vis(x, 0); >>> >>> Now even if the canvas is recreated with the same memory space there is >>> no more double-entry bug. Are there any potential regressions with this >>> model? The canvas is getting freed so I cannot imagine this posing any >>> problems but then again I am sure I may be missing something... >> >> this only handles the case when the GOP is part of a toplevel window. >> >> The other case is when the GOP's parent isn't toplevel. When the >> window of such a parent is closed, the canvases themselves aren't >> destroyed, but the editors should be. >> >> So I think the best way is to get rid of sub-editors recursively. >> I may be mistaken, though, because there are some partial workarounds >> already in the code. Apparently, Miller had been aware of the issue >> but then things went their own way, somehow. >> >> 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 I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Personally, I'm hoping to put band-aids on as many manaifestations of the problem as I can track down (so thanks for this one :) and then re-design the whole editor creation and destruction strategy for 0.44 - it looks like it can never be fully debugged the way it's stet up now! Miller On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote: > On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: > ... > >Wow! You just helped me finally solve this riddle! Could it be really > >this simple? In canvas_free() call inside g_canvas.c simply add the > >following 2 lines: > > > > if (x->gl_editor) > > canvas_destroy_editor(x); > > > >I added them right below > > > > if (x == glist_getcanvas(x)) > > canvas_vis(x, 0); > > > >Now even if the canvas is recreated with the same memory space there is > >no more double-entry bug. Are there any potential regressions with this > >model? The canvas is getting freed so I cannot imagine this posing any > >problems but then again I am sure I may be missing something... > > this only handles the case when the GOP is part of a toplevel window. > > The other case is when the GOP's parent isn't toplevel. When the > window of such a parent is closed, the canvases themselves aren't > destroyed, but the editors should be. > > So I think the best way is to get rid of sub-editors recursively. > I may be mistaken, though, because there are some partial workarounds > already in the code. Apparently, Miller had been aware of the issue > but then things went their own way, somehow. > > 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
Re: [PD-dev] deadly leak
On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: ... Wow! You just helped me finally solve this riddle! Could it be really this simple? In canvas_free() call inside g_canvas.c simply add the following 2 lines: if (x->gl_editor) canvas_destroy_editor(x); I added them right below if (x == glist_getcanvas(x)) canvas_vis(x, 0); Now even if the canvas is recreated with the same memory space there is no more double-entry bug. Are there any potential regressions with this model? The canvas is getting freed so I cannot imagine this posing any problems but then again I am sure I may be missing something... this only handles the case when the GOP is part of a toplevel window. The other case is when the GOP's parent isn't toplevel. When the window of such a parent is closed, the canvases themselves aren't destroyed, but the editors should be. So I think the best way is to get rid of sub-editors recursively. I may be mistaken, though, because there are some partial workarounds already in the code. Apparently, Miller had been aware of the issue but then things went their own way, somehow. Krzysztof ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
> Deadly leak hits me, and my students, regularly and annoyingly when we > are patching in a certain way. > > I don't know about other bugs. This one is really not as convoluted > as you suggest -- its fatal consequences are, perhaps, but not the bug > itself. > > The real source of the bug is not freeing the GOP's editor. The fix > is either to free it, for example by a recursive traversal in > canvas_destroy_editor(), or to rework the g_text.c so as not to need > the editor in the first place. > > The editor is created whenever there is a gatom inside of a GOP -- > because vised gatoms use text responders (aka rtexts). > > For the time being the workaround, when patching, is not using rtexts > (read: gatoms) in a GOP. > > Krzysztof Wow! You just helped me finally solve this riddle! Could it be really this simple? In canvas_free() call inside g_canvas.c simply add the following 2 lines: if (x->gl_editor) canvas_destroy_editor(x); I added them right below if (x == glist_getcanvas(x)) canvas_vis(x, 0); Now even if the canvas is recreated with the same memory space there is no more double-entry bug. Are there any potential regressions with this model? The canvas is getting freed so I cannot imagine this posing any problems but then again I am sure I may be missing something... Any thoughts? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Le 2011-12-14 à 12:49:00, Ivica Ico Bukvic a écrit : So what part of the code specifically binds keyboard and mouse actions to a canvas? Look for the name as it appears in Tcl commands going to Pd. From what it looks like in commands to/from Tcl, you can see that it is a ".x%lx" format-string. You can find that this exact format string is used in editor_new (whereas all other cases use longer format strings intended directly for sys_vgui). This string is used as an argument to guiconnect_new, which calls pd_bind. Also, editor_free calls guiconnect_notarget which schedules guiconnect_free which calls pd_unbind. 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. Implicit binding is a DesireData-only feature, in which binbuf_eval handles a « no such object » error by reparsing the receive-symbol as a t_pd*, after checking that it exists (object_table->exists(target)) and that it's a non-zombie (object_table->get(target)). This allows for deleting the whole guiconnect business, including deleting the bug that we're talking about. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Mathieu Bouchard 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
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. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
_ From: Ivica Ico Bukvic [mailto:i...@vt.edu] Sent: Tuesday, December 13, 2011 4:18 AM To: Hans-Christoph Steiner; Jonathan Wilkes; Krzysztof Czaja; pd-dev Subject: Re: [PD-dev] deadly leak 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. Well, as usual, I spoke too soon. Now that the infinite undo is nearing its full implementation, I have tripped over this bug again even though it has been gone for almost a year of thorough testing. The problem arises when a canvas is created (so far tested only with an abstraction--the larger it is, the more likely the bug is to surface), then cut, and then undo cut, sometimes it is recreated in the same memory location as the previous one. (e.g. do a gop object that in its visible part has loadbang->window_name->symbol). Several cuts and undos will eventually recreate the object in new memory space and the problem will temporarily disappear. OTOH, as long as it is recreating in the same memory space, entry bug becomes double entry, then triple entry, etc. The crash occurs when one asks for double (triple, quadruple. etc.) free when deleting an object or doing anything like it destructive that has danger of tripping over pointers that have been already freed. At one point Mathieu suggested that unbinding is not doing its job properly but according to my preliminary debugging of pd_unbind calls (if that is what unbinds things with the canvas or is it?) it seems to be calling it ok for each canvas and subcanvas and yet everything is getting bound multiple times to a canvas. One potentially crazy explanation would be that with larger memory allocation chunks perhaps OS is trying to find best location and if it is identical to one that has just been freed, it puts it there and hence the symptom. Although this still does not explain why unbind does not unbind key presses/mouse clicks etc. Any ideas? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
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 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 > > To: pd-dev > > 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
Re: [PD-dev] deadly leak
- Original Message - > From: Hans-Christoph Steiner > To: Jonathan Wilkes ; Krzysztof Czaja > ; pd-dev > Cc: Ivica Ico Bukvic > Sent: Monday, December 12, 2011 9:40 PM > Subject: Re: [PD-dev] deadly leak > > > 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. The comment in the changelog I referenced below was from 2011-03-26. In 2011-04-03 there's this: *removed some of the workarounds for the aforesaid double-entry bug which proved to be fixes for the symptoms rather than the core problem Then in 2011-04-11: *finally discovered the root of all double-entry bugs (fingers crossed) and reverted all other previous workarounds for this problem. That's the last entry in the changelog I see that is related to this issue, but I only tested my crasher patch on 2011-12-09 to confirm that the crash or double-entry is indeed gone in this case with Pd-l2ork. -Jonathan > > .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 >> > To: pd-dev >> > 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
Re: [PD-dev] deadly leak
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 > > To: pd-dev > > 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
Re: [PD-dev] deadly leak
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 > To: Krzysztof Czaja ; pd-dev > Cc: Ivica Ico Bukvic > 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 >> To: pd-dev >> 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
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 > To: pd-dev > 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] 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
