Menu
▾
▴
#68 subpatch clearing itself crashes Pd
Tested on Linux with pd-0.39-2 from Miller's site.
Steps to reproduce:
start pd
load the patch attached to this post
click the bng
close the patch
load the patch again
click the bng
=> crash
OR
start pd
load the patch
open the subpatch
(optionally: close the subpatch)
click the bng
=> crash
Here's a gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 27794)]
pd_bang (x=0x11) at m_pd.c:269
269 m_pd.c: No such file or directory.
in m_pd.c
(gdb) where
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x0808a61b in outlet_bang (x=0x3) at m_obj.c:328
#2 0x080765ad in bng_bout2 (x=0x81f2790) at g_bang.c:294
#3 0x080767f6 in bng_newclick (z=0x11,
glist=0x81f2338, xpix=74, ypix=70,
shift=0, alt=0, dbl=0, doit=1) at g_bang.c:343
#4 0x0806e907 in gobj_click (x=0x0, glist=0x11,
xpix=17, ypix=17, shift=17,
alt=17, dbl=17, doit=17) at g_editor.c:92
#5 0x0805b557 in graph_click (z=0x81f2338, glist=0x11,
xpix=74, ypix=70,
shift=0, alt=0, dbl=17, doit=1) at g_graph.c:1059
#6 0x0806e907 in gobj_click (x=0x0, glist=0x11,
xpix=17, ypix=17, shift=17,
alt=17, dbl=17, doit=17) at g_editor.c:92
#7 0x08070a97 in canvas_doclick (x=0x81ecd08, xpos=74,
ypos=70, which=1,
mod=0, doit=1) at g_editor.c:1094
#8 0x0807119d in canvas_mousedown (x=0x11, xpos=0,
ypos=0, which=0, mod=0)
at g_editor.c:1252
#9 0x08089789 in pd_typedmess (x=0x81ecd08, s=0x0,
argc=0, argv=0x80cf488)
at m_class.c:728
#10 0x08089665 in pd_typedmess (x=0x81f25f8, s=0x0,
argc=4, argv=0x80cf468)
at m_class.c:749
#11 0x0808c32f in binbuf_eval (x=0x11,
target=0x81f25f8, argc=0, argv=0x0)
at m_binbuf.c:574
#12 0x08091fdf in socketreceiver_read (x=0x81ec2f0,
fd=7) at s_inter.c:540
#13 0x0809180f in sys_domicrosleep (microsec=17,
pollem=1) at s_inter.c:180
#14 0x08092660 in sys_pollgui () at s_inter.c:823
#15 0x0808fe5b in m_scheduler () at m_sched.c:466
#16 0x08095b1b in main (argc=17, argv=0x11) at s_entry.c:27
Discussion
Anonymous
pd patch with GOP subpatch, exhibiting crashing behaviour
Logged In: YES
user_id=564396
this has nothing to do with GOP, therefore i renamed the
bug-report.
what happens: an object emits a message; the calling
function is pushed to the stack; the message triggers the
deletion of the object; after the message is done, the
calling function (of the now deleted object) is popped back
from the stack: but alas! the entire environment has changed
and nothing is as it should be....stack corruption -> crash.
personally i think, that this is NOT a bug in pd but rather
a bug in the patch (but i am repeating myself...)
Logged In: YES
user_id=564396
the really interesting thing here, is that your patch will
not crash when you only click on the [bng] once. you have to
follow the steps as described.
i add another patch that triggers the crash reliable and
without the complicated procedure (just click it and crash it)
raised priority, since crashers should be fixed.
patch triggering the bug
Logged In: YES
user_id=769033
Some comments about pd-0.40-1 from Miller's site:
1. Start pd, load gop-subpatch-self-clear-crash.pd, click
bang => no crash, subpatch is cleared correctly
2. Start pd, load gop-subpatch-self-clear-crash.pd, open
subpatch, click bang => crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211095376 (LWP 13534)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x82371f8) at m_obj.c:328
#2 0x0808f101 in bng_newclick (z=0x82415c8,
glist=0x8241200, xpix=136,
ypix=139, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294
#3 0x0808a36a in canvas_doclick (x=0x8241200, xpos=136,
ypos=139, which=1,
mod=0, doit=1) at g_editor.c:92
#4 0x0808b14b in canvas_mousedown (x=0x8241200, xpos=136,
ypos=139, which=1,
mod=0) at g_editor.c:1242
#5 0x080a79c5 in pd_typedmess (x=0x8241200, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#6 0x080a7632 in pd_typedmess (x=0x8241418, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#7 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#8 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#9 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#10 0x080b7967 in sys_pollgui () at s_inter.c:825
#11 0x080b2f53 in m_scheduler () at m_sched.c:466
#12 0x080b651a in sys_main (argc=1, argv=0xbfcbb4a4) at
s_main.c:316
#13 0x080bf7cf in main (argc=136563232, argv=0x8242b00) at
s_entry.c:27
3. Start pd, load gop-subpatch-self-clear-crash.pd, open
subpatch, close subpatch, click bang => crash
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210849616 (LWP 13563)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x82373c0) at m_obj.c:328
#2 0x0808f101 in bng_newclick (z=0x823cbc0,
glist=0x8237230, xpix=72,
ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294
#3 0x0805be1a in graph_click (z=0x8237230, glist=0x8237090,
xpix=72, ypix=70,
shift=0, alt=0, dbl=0, doit=1) at g_graph.c:1052
#4 0x0808a36a in canvas_doclick (x=0x8237090, xpos=72,
ypos=70, which=1,
mod=0, doit=1) at g_editor.c:92
#5 0x0808b14b in canvas_mousedown (x=0x8237090, xpos=72,
ypos=70, which=1,
mod=0) at g_editor.c:1242
#6 0x080a79c5 in pd_typedmess (x=0x8237090, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#7 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#8 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#9 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#10 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#11 0x080b7967 in sys_pollgui () at s_inter.c:825
#12 0x080b2f53 in m_scheduler () at m_sched.c:466
#13 0x080b651a in sys_main (argc=1, argv=0xbfeee6d4) at
s_main.c:316
#14 0x080bf7cf in main (argc=136541136, argv=0x823e958) at
s_entry.c:27
4. Start pd, load crash-1518030.pd, click "bang" => crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210677584 (LWP 13575)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x8237408) at m_obj.c:328
#2 0x080aa8eb in outlet_bang (x=0x82373d0) at m_obj.c:328
#3 0x080aa8eb in outlet_bang (x=0x823cce0) at m_obj.c:328
#4 0x080a77a1 in pd_typedmess (x=0x823cccc, s=0x8119364,
argc=0,
argv=0x811a950) at m_class.c:641
#5 0x080abba4 in binbuf_eval (x=0x823cc68, target=<value
optimized out>,
argc=1, argv=0xbfa50e8c) at m_binbuf.c:673
#6 0x0805f46d in message_click (x=0x823ccb0, xpos=91,
ypos=65, shift=0,
ctrl=0, alt=0) at g_text.c:300
#7 0x08063721 in text_click (z=0x823ccb0, glist=0x8237080,
xpix=91, ypix=65,
shift=0, alt=0, dbl=0, doit=1) at g_text.c:1065
#8 0x0808a36a in canvas_doclick (x=0x8237080, xpos=91,
ypos=65, which=1,
mod=0, doit=1) at g_editor.c:92
#9 0x0808b14b in canvas_mousedown (x=0x8237080, xpos=91,
ypos=65, which=1,
mod=0) at g_editor.c:1242
#10 0x080a79c5 in pd_typedmess (x=0x8237080, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#11 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#12 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#13 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#14 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#15 0x080b7967 in sys_pollgui () at s_inter.c:825
#16 0x080b2f53 in m_scheduler () at m_sched.c:466
#17 0x080b651a in sys_main (argc=1, argv=0xbfa52a44) at
s_main.c:316
#18 0x080bf7cf in main (argc=0, argv=0x0) at s_entry.c:27
Logged In: YES
user_id=1709568
Originator: NO
Just another example that triggers the same bug (dunnow why I can't attach a file so I "transcribe" it here):
[bng]
|
[f 0]
|
[find f, cut(
|
[s pd-thisFile'sName.pd]
I don't agree with zmoelnig in that it is not a bug.
Calling functions and stacks are implementation details the patch author shouldn't need to be aware of.
What the patch is doing is deleting an object. The message causing the deletion was triggered by (a message that was triggered by[...]) that object, so what?
There's nothing semantically incorrect in doing that.
Logged In: YES
user_id=569446
Originator: NO
Hi,
sistisette wrote:
> There's nothing semantically incorrect in doing that.
There is. You may be missing some implications of Pd's "depth first
message passing" as described in the manual, chapter "2.3.2. depth
first message passing": [1]
"Each message sets off a tree of consequent messages." As a message is
generated by an object this also means that each (message) object sets
off a tree of messages. Every branch of messages has to finish at some
point. If it doesn't, you have an error in your patch, that will
result in an infinite message loop or "stack overflow". The manual has
an example for this, but you can also just bang an [until] without
stopping it to make such a stack overflow without any backwards
connections.
Now how does this relate to "suicide" messages, that is, messages that
will result in a deletion of the object that generated the message?
Lets look at the [pd x] subpatch which has a [; pd-x clear( suidice
message: As soon as you click this message, it will start a "message
tree of consequent messages." This message tree has to finish, and the
end point here would be the clearing of the subpatch including the
message box that initiated the suidice.
At first look this may seem okay, but a powerful and important feature
of Pd is, that an object or message can be a node for several message
branches. [trigger bang float] is one example for this: Pd will first
execute the tree below the right float outlet completely, and when
this is finished, it will come back to the [t b f] to work on the left
bang outlet's tree. With messages this also is possible, e.g. by
seperating messages with a comma or semicolon: [; pd-x clear; pd-x msg
100 100 hello world(: First this message will clear [pd x] then it
will evaluate the second part of the message and put a "hello world"
message into [pd x].
To be able to do this Pd has to save the current branching node
somehow to come back there later, when the first branch has finished.
But now we have a problem, if a message tries to commit suicide and
thus deletes the node that according to Pd's language rules and logic
needs to be evaluated again, after the "depth first tree" has come to
an end!
As the node was deleted, this is impossible, the correct data flow
cannot be restored and that's why these messages indeed are
semantically incorrect just like infinite message loops. Of course Pd
should not die if someone attempts suidide, but still these kinds of
messages are illegal constructs.
Logged In: YES
user_id=1709568
Originator: NO
>But now we have a problem, if a message tries to commit suicide and
>thus deletes the node that according to Pd's language rules and logic
>needs to be evaluated again, after the "depth first tree" has come to
>an end!
When the moments come to evaluate the "second branch" of a node which has been deleted as a result of the execution of its first branch, the object no more exists, so the most logical action to take (seems to me) would be just not to execute the pending "future branches". The tree does finish. Another acceptable option would be to output an error message that says that the message tree can't be completed. Indeed that would be the same thing, with or without an error message in the output.
The part you quote from the manual says that the message tree has to come to an end. It does not say that nothing must change until it comes to an end, as far as i see. You are adding that part. You may be correct, but that's not a consequence of the depth first message passing.
Neither the self-clearing patch nor my "find f,cut" example try to generate a tree that does not end.
Not to mention that in theese examples the branch that ends up with the deletion of the message is the last branch, so the evaluation of the next branch would be just to detect that it didn't exist anyway.
>To be able to do this Pd has to save the current branching node
>somehow to come back there later, when the first branch has finished.
Yeah. It is the "somehow" that has been chosen that does not take into account the possibility of dinamically deleting objects.