[PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd

[Frank Barknecht]

Hallo,

SourceForge.net hat gesagt: // SourceForge.net wrote:
> Comment By: Matteo Sisti Sette (sistisette)
> Date: 2007-02-10 19:45
> 
> Message:
> 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.

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. 

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__