Patches item #1890705, was opened at 2008-02-10 18:18
Message generated for change (Settings changed) made by pland
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1890705&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Plans Casal (pland)
>Assigned to: Miller Puckette (millerpuckette)
Summary: Repairing s_inter.c so it behaves with OSX 10.5
Initial Comment:
Calls to sys_guicmd between fork() and exec were causing 'you must exec!' errors to do with new Frameworks policy. This patch puts the sys_guicmd before the fork, and was tested on 10.5.1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1890705&group_…
On Feb 12, 2008, at 5:28 AM, David Plans Casal wrote:
>
> On 11 Feb 2008, at 19:39, Hans-Christoph Steiner wrote:
>
>> I'd like to start the release branch for Pd-extended 0.40.3 in two
>> weeks. Is there any work pending that should get included?
>
> I'd just like to include the s_inter.c patch so those nasty
> framework errors dissapear.
>
> Should I commit to /svnroot/pure-data/branches/pd/pd-0.40-3 (are
> you going to work on extended version from that branch?)
You shouldn't commit to any of the 'pd' branches, they are just
mirrors of Miller's repository. There are currently separate
branches for pd-extended, this is the one you want:
http://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-
extended/v0-40/
Also, you could commit the patch file to HEAD of packages/patches,
unless Miller has included it in his sources. That way we can keep
track of what to add to 0.41 when making the pd-extended branch. I
suppose this isn't an ideal system, I am up for changing it now that
we have SVN in place.
.hc
>
> David
>
>> If so,
>> let me know when it'll be done. Otherwise those changes will have
>> to be merged into the release branch to make it into the release.
>>
>> Woo hoooo! Let's do the next Pd-extended release sooner than a year
>> after the last! :D
>>
>> .hc
>>
>> ---------------------------------------------------------------------
>> ---
>> ----
>>
>> http://at.or.at/hans/
>>
>>
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev(a)iem.at
>> http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
----
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:30
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
2) Click on the [connect...( msg box on both
3) Click on the [36000( on the SEND patch, to send 36000 messages.
--> None of the two PD's freeze. All works fine. Note that, if the
netreceive was within the same patch, 12000 messages would be sufficient to
make pd freeze. Dunnow why.
4) Now click on the [36000( on the RECEIVE patch, to send 36000 messages
the other way.
--> None of the two PD's freeze. All works fine.
5) Now connect the [netreceive] in the RECEIVE patch to the [list prepend
send] below: just where you see the comment that reads "*here*"
6) In the SEND patch, click on the [36000( message box. Now the RECEIVE
patch will be echoing back every message it receive (but the SEND patch
won't, so there's no infinite loop).
--> BOTH PD's freeze!!! They don't eat up any CPU, they simply become
unresponsive.
I can't even close them, I have to kill them. Killing any of them will
"free" the other.
7) Try playing with the number of messages sent (editing the message
boxes). For some reason, the number of messages needed to freeze pd in this
test is greater than the number needed to free a single instance of PD with
netsend and netreceive in the same patch (bug_netsend.pd). With 36000
messages I am certain to freeze both PDs with one click.
With about 10000 messages, it usually doesn't freeze at the first click,
but if I click histerically on the message box I almost certainly have it
freeze.
This means (i guess) that the many messages don't need to be sent in zero
logical times to freeze pd, they just need to be sent within a very little
span of time.
Note that I wouldn't expect netsend and netreceive to be able to handle an
arbitrarily big amount of messages in an arbitrarily small time interval,
but in case they can't handle it, I do expect PD to output an error or
warning message, and to keep working without freezing forever.
I had this problem in a real-life huge patch, and I had no clue of what
was happening. It was just a lucky guess to investigate netsend/netreceive
because I had experienced another (apparently unrelated) bug with
netsend/netreceive.
At the very least, it is a bug that PD stop working without giving the
least clue of what's wrong; also, there's no need to stop execution at all.
After issuing a warning and discarding overflowing messages, and possibly
breaking the current message-tree being processed, PD could perfectly keep
working.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:11
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:11
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:10
Message:
Logged In: YES
user_id=1709568
Originator: YES
please ignore the previous comment, it was incomplete and i didn't mean to
send it.
I'll post the complete comment and attached files later
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:08
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:11
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:11
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:10
Message:
Logged In: YES
user_id=1709568
Originator: YES
please ignore the previous comment, it was incomplete and i didn't mean to
send it.
I'll post the complete comment and attached files later
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:08
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:11
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:10
Message:
Logged In: YES
user_id=1709568
Originator: YES
please ignore the previous comment, it was incomplete and i didn't mean to
send it.
I'll post the complete comment and attached files later
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:08
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:10
Message:
Logged In: YES
user_id=1709568
Originator: YES
please ignore the previous comment, it was incomplete and i didn't mean to
send it.
I'll post the complete comment and attached files later
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:08
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:08
Message:
Logged In: YES
user_id=1709568
Originator: YES
More and more and more weird.....
Have a look at the attached SEND.pd and RECEIVE.pd
1) Open them IN TWO SEPARATE INSTANCES OF PD
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:07
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: RECEIVE.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 12:06
Message:
Logged In: YES
user_id=1709568
Originator: YES
File Added: SEND.pd
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…
Bugs item #1891819, was opened at 2008-02-12 10:32
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&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.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: too many messages to NETSEND freeze pd forever (but 0% cpu)
Initial Comment:
If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.
Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]
Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.
Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-12 11:20
Message:
Logged In: YES
user_id=1709568
Originator: YES
The problem seems to be in netreceive, not netsend.
I have tried by eliminating the netreceive, and using another application
to receive the data.
I increased the number of message sent by a factor of 30 and no problem.
Obviously netsend blocks for a considerable time, needed to send all the
data (a few seconds), but then PD works normally.
Another note: the critical amount of data needed to hang PD seems to be
dependent on the total size, not the number of messages (which is not
surprising), and seems to be around 32 kB (something more than 32kB
indeed).
May I guess it is an issue with some buffer that gets full?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891819&group_…