Bugs item #1655670, was opened at 2007-02-09 02:08
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…
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: Open
Resolution: None
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: 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_…
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_…
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_…
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_…
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: Open
Resolution: None
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 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_…
Patches item #1656382, was opened at 2007-02-09 15:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1656382&group_…
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: externals
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stephen Sinclair (radarsat1)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSCx - assign TTL only for multicast groups
Initial Comment:
I realized that in my previous changes to OSCx, I caused sendOSC to set the TTL value for any UDP connection. This could cause unexpected default behaviour, whether using multicast or not, when trying to use OSC on a long network connection, outside of a local subnet, such as between continents. This patch changes the behaviour so that it only sets TTL for actual multicast IP addresses. It also rejects requests to create connections on the range of multicast addresses reserved for routing information.
(This is described here: http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/index.html)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1656382&group_…
Bugs item #1655670, was opened at 2007-02-09 02:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…
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: Open
Resolution: None
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…
Bugs item #1655662, was opened at 2007-02-09 01:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655662&group_…
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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: .xa10120: no such object
Initial Comment:
Hi,
This seems to happen under "random" circumstances. It happened to me with every kind of patches (simple and complex) and usually NOT in a sistematic manner (that is, the same patch which once triggers the bug, after restarting PD never does again...)
However, this patch that I attach does sistematically make this happen, at least to me under Windows XP.
The following error message appears in the output window:
>> .xa10120: no such object
This particular patch uses "scripting", i.e. it creates and deletes an object in a subpatch iteratively; however, I saw this same bug happen a lot of times with patches which didn't make any use of scripting at all. I attach this just because it is the only one I have that is sure to trigger the bug.
Sorry I can't "isolate" it further.
Matteo Sisti Sette
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655662&group_…
Patches item #1532439, was opened at 2006-08-01 16:07
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1532439&group_…
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: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guenter Geiger (ggeiger)
Assigned to: Miller Puckette (millerpuckette)
Summary: arrays on 64-bit archs
Initial Comment:
Arrays are currently not working correctly on 64 bit
architectures. This patch implements a solution for the
problem by introducing a ASTRIDE constant, which is the
ratio sizeof(union word)/sizeof(t_sample). The drawback
of this method is that arrays use twice as much memory
on 64 bit archs.
The patch should not affect 32 bit architectures, so
it might be a valid temporal fix.
Guenter
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-02-08 17:49
Message:
Logged In: YES
user_id=564396
Originator: NO
seems to be fixed in 0.41
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2006-08-14 06:38
Message:
Logged In: YES
user_id=313747
I don't have a 64 bit machine yet to test this on... will
fix things as soon as I can test them.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1532439&group_…
Bugs item #1085018, was opened at 2004-12-14 10:59
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1085018&group_…
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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Guenter Geiger (ggeiger)
Assigned to: Miller Puckette (millerpuckette)
Summary: Arrays on 64-bit machines
Initial Comment:
The float arrays on 64 bit machines do not work correctly.
The problem comes from the size of the t_word union,
which is exactly the size of a float on 32 bit
machines, but its double the
size of a float on 64 bit machines. This means that
routines
which treat the array as float* (the ones in d_array)
treat them
differently as those in g_array (which think of them as
t_word elements).
This could be fixed in several (all suboptimal) ways.
I'm leaving this up to Miller.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-02-08 17:46
Message:
Logged In: YES
user_id=564396
Originator: NO
seems to be fixed in 0.41
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1085018&group_…
Bugs item #1654666, was opened at 2007-02-08 00:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1654666&group_…
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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: sending a cut message to an "invisible" subpatch makes crash
Initial Comment:
If you have a subpatch, and send a "cut" message to it when it is not in "visible" state (i.e. it is not open), pd crashes.
This may happen when using scripting, if for example you send a "find foo" message followed by a "cut" message. If the object does not exist (and the subpatch hasn't been made explicitly visible), the cut message will reach the canvas when it is invisible.
See the attached example.
Tested on 0.40.2 on Windows XP.
Matteo Sisti Sette
matteo dot sistisette at email dot it
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1654666&group_…
Bugs item #1650752, was opened at 2007-02-02 11:00
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1650752&group_…
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: pd-extended
Group: v0.39.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke Iannini (lukeiannini)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: Select Cursor does not Correspond to Text In New PD-E
Initial Comment:
Basically the change to the new font(s) has caused the mouse cursor to be inaccurate when selecting text. It seems to be assuming the wider courier font is in use. This combined with the next bug I'm about to submit regarding backwards delete has made things a bit tedious.
This is on i386 and PPC OS X (though I assume this is platform independent) with the lastest 392 autobuilds.
A picture is included with a badly rendered OmniDazzle cursor in the position of the actual cursor (since the cursor is not included in OS X screengrabs), and the text cursor in the position that results from a click at that point.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-02-05 10:02
Message:
Logged In: YES
user_id=27104
Originator: NO
This stuff is still a work in progress. Most importantly, you need to
have DejaVu Sans Mono font currently. Otherwise, it picks a proportional
font, and causes the misalignment.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-02-02 18:01
Message:
Logged In: YES
user_id=1658640
Originator: NO
I can confirm this behavior, using the intel mac build.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1650752&group_…