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?
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
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
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
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
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
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Krzysztof Czaja -
Miller Puckette