[PD-dev] [ pure-data-Bugs-1655670 ] misterious crashes when scripting

[SourceForge.net]

Bugs item #1655670, was opened at 2007-02-09 02:08
Message generated for change (Comment added) made by fbar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.40.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: misterious crashes when scripting

Initial Comment:
Hi,

I'm sorry I can't be more specific.
The attached patch makes PD crash.

Look at the patch, it has a lot of comments.
I have reduced it to the minimum that I could.

I use messages to dinamically create and delete an object within a (sub)subpatch and connect it.

I pass a float "through" the subpatch when the dinamically created objects and connections are made so that it can pass through.

When doing a single iteration, that works.
However, for some reason, if I put it into a loop (by feeding back the output to the input) it crashes. Note that the loop is not infinite, since I have a decrement and a condition to stop it after a number of iterations.
It crashes even with a couple of iterations.

----------------------------------------------------------------------

>Comment By: Frank Barknecht (fbar)
Date: 2007-02-10 18:49

Message:
Logged In: YES 
user_id=569446
Originator: NO

Hi,

I'm closing this bug as it's in fact a duplicate of bug number 1518030.

1518030 has a clearer example to illustrate the patch, so I'd rather keep
that one.

Ciao
-- 
Frank

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2007-02-10 16:37

Message:
Logged In: YES 
user_id=1709568
Originator: YES

Thank you fbar, this explains better where the bug is and helps me
isolating it in the following patch, which I attach as testbug4b.pd and
which I reproduce here as it is very simple:
[bng]
|
[f]
|
[find f, cut(
|
[s pd-testbug4b.pd]

(assuming the file is saved as testbug4b.pd)

However, I think this still is a bug.
1) First, because whenever a program crashes it is a bug, no matter how
incorrect the input (in this case the patch).

2) Secondly, because I don't see what is semantically wrong about deleting
the [f] even if the message that deletes it has been originated by itself.
That is an implementation issue.
Let's look at the flux of data, or messages.
[f] outputs a message that is a float.
This message hits the message box and causes it to output two messages: 
-a "find f", which reaches the [s], is sent to the canvas, and causes the
[f] to be selected
-a "cut", which reaches the [s], is sent to the canvas, and causes the [f]
to be deleted.
...so what?

If, internally, the flux of data is tracked somewhere "inside" the object
that originates it, it is a matter of implementation that the patch author
need not care about. And that is an implementation that doesn't completely
take into account the possibility that objects may dynamically be deleted.
File Added: testbug4b.pd

----------------------------------------------------------------------

Comment By: Frank Barknecht (fbar)
Date: 2007-02-10 01:21

Message:
Logged In: YES 
user_id=569446
Originator: NO

This actually is a "I shoot myself in the foot to commit suicide" bug in
the patch. ;) 

What is happening here: After triggering the "30" the [t f f b] in [pd
one] will first delete the [f] in [pd two] and then recreate it. This is
okay. Then the 30 will be sent from the middle outlet of the [t f f b] and
open the spigot. From the left outlet of [t f f b] it will then be
decremented to 29 and go into [pd two] where it is passed through the [f].
This moment is important so lets mark it with <crash-reason>. The 29 will
then leave [pd two] and after that leave [pd one] as well, go through the
outside [t f f] and enter [pd one] again. 

Now as it reaches [t f f b] in [pd one] again, where it will again first
initiate the bang that cuts the [f] in [pd two]. But now the problem
occurs: In the past at time <crash-reason> the [f] in [pd two]  was, what
was triggering the second time, the [f] in [pd two] should be deleted, so
to Pd this is a case of suicide: The [f] object is trying to delete itself
and that's illegal. It's not a bug in Pd - although Pd shouldn't crash -
it's more a bug in the patch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_id=55736