Hans and all,
Following is not the case with either 0.41.4 or 0.43.
Create a new patch->create a subpatch (e.g. [pd test]) which will immediately open upon creation->close the main patch (with or without saving)->crash. It happens consistently on my machine.
However, if one closes the subpatch ([pd test]) and then closes the main patch, it does not crash.
The tough part is even when runnning pd with debugging enabled and stderr flag the only output I get at crash is menuclose 2 and then segfault.
Here are two examples of the relevant output: 1) (CRASHING)
.x93f9c38 relocate 450x300+0+0 450x300+1+50 ; .x93f9c38 menuclose 0 ; pd watchdog ; .x93f9c38 menuclose 2;
.x93f8ff8 relocate 450x300+0+0 450x300+12+127 ; Segmentation fault pd_gui: pd process exited
2) (NON-CRASHING) .xa44ee70 motion 354.0 8.0 0 ; .xa44ee70 motion 362.0 3.0 0 ; .xa44ee70 menuclose 0 ; pd watchdog ; .xa44fe88 relocate 450x300+0+0 450x300+1+50 ; .xa44fe88 menuclose 0 ; .xa44fe88 menuclose 2;
It seems the first one is trying to relocate window after it has been destroyed? Something seems out of order...
Ico
On Mon, 2009-11-02 at 09:24 -0500, Ivica Ico Bukvic wrote:
Hans and all,
Following is not the case with either 0.41.4 or 0.43.
Create a new patch->create a subpatch (e.g. [pd test]) which will immediately open upon creation->close the main patch (with or without saving)->crash. It happens consistently on my machine.
However, if one closes the subpatch ([pd test]) and then closes the main patch, it does not crash.
The tough part is even when runnning pd with debugging enabled and stderr flag the only output I get at crash is menuclose 2 and then segfault.
OK, here's a more verbose version of the error log. Please see attached. For some dubious reason I had to add following (redundant?) line to the DEBUG part in order to get any debug output:
line 690: } if (sys_debuglevel & DEBUG_MESSUP) fprintf(stderr, "%s", sys_guibuf + sys_guibufhead); //following is totally redudant but without it I got no output fprintf(stderr, "%s", sys_guibuf); sys_guibufhead += msglen; sys_bytessincelastping += msglen;
Ico
So I finally traced this down to the following call in g_editor.c.
I am not however submitting the patch as I am not entirely sure this is the right approach or a solution without regressions.
else /* make invisible */ { int i; t_canvas *x2; if (!x->gl_havewindow) { /* bug workaround -- a graph in a visible patch gets "invised" when the patch is closed, and must lose the editor here. It's probably not the natural place to do this. Other cases like subpatches fall here too but don'd need the editor freed, so we check if it exists. */ if (x->gl_editor) canvas_destroy_editor(x); return; } //Commenting call below out apparently solves the problem //however, I am also //not sure what are other potential regressions //Curiosity question: why do we need to get scroll on something //that we are closing anyhow? //BEGIN OFFENDING CALL //sys_vgui("pdtk_canvas_getscroll .x%lx.c\n", x); //END OFFENDING CALL glist_noselect(x); if (glist_isvisible(x)) canvas_map(x, 0); if (x->gl_editor) canvas_destroy_editor(x); sys_vgui("destroy .x%lx\n", x); for (i = 1, x2 = x; x2; x2 = x2->gl_next, i++) ; sys_vgui(".mbar.find delete %d\n", i); /* if we're a graph on our parent, and if the parent exists and is visible, show ourselves on parent. */ if (glist_isgraph(x) && x->gl_owner) { t_glist *gl2 = x->gl_owner; if (glist_isvisible(gl2)) gobj_vis(&x->gl_gobj, gl2, 0); x->gl_havewindow = 0; if (glist_isvisible(gl2)) gobj_vis(&x->gl_gobj, gl2, 1); } else x->gl_havewindow = 0; canvas_updatewindowlist(); }
On Nov 2, 2009, at 11:27 AM, Ivica Ico Bukvic wrote:
On Mon, 2009-11-02 at 09:24 -0500, Ivica Ico Bukvic wrote:
Hans and all,
Following is not the case with either 0.41.4 or 0.43.
Create a new patch->create a subpatch (e.g. [pd test]) which will immediately open upon creation->close the main patch (with or without saving)->crash. It happens consistently on my machine.
However, if one closes the subpatch ([pd test]) and then closes the main patch, it does not crash.
The tough part is even when runnning pd with debugging enabled and stderr flag the only output I get at crash is menuclose 2 and then segfault.
Hmm, I can't reproduce this using Pd-extended 0.42.5-20091104 on Mac OS X 10.5.8/Intel. That bug does ring a bell, but I thought it was fixed.
.hc
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Hmm, I can't reproduce this using Pd-extended 0.42.5-20091104 on Mac OS X 10.5.8/Intel. That bug does ring a bell, but I thought it was fixed.
.hc
It is definitely there on my end (svn checked out approx. a week ago). The fix I suggested definitely fixes it. I've tested it on the last l2ork rehearsal on 9 machines running concurrently and it was rock solid for over an hour and a half running a complex patch and obviously using the fix I sent out in my previous email. Speaking of that fix, it seems to me that the additional "check_geometry" call is indeed superfluous as the debugger output shows that last check_geomtery shifts the canvas a tiny bit (unless this is compiz's doing on Linux), introducing inconsistency to the window/canvas position (if I understand correctly what check_geometry does).
Best wishes,
Ico
-
Hans-Christoph Steiner -
ico＠vt.edu -
Ivica Ico Bukvic