Pd-dev February 2008

pd-dev@lists.iem.at

23 participants
81 discussions

Start a nNew thread

how to checkout svn
by marius schebella 17 Feb '08

17 Feb '08

hi, how can I checkout the latest pd-extended sources? marius.

4 3

[ pure-data-Bugs-1891819 ] too many messages to NETSEND freeze pd forever (but 0% cpu)
by SourceForge.net 17 Feb '08

17 Feb '08

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-17 17:12 Message: Logged In: YES user_id=1709568 Originator: YES I guess it is NOT related to 1891178, since that bug is fixed in 0.41-2 and this one is not. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-13 12:59 Message: Logged In: NO I think this bug MAY be related to bug 1891178. When big bursts of messages are sent through netsend, there are random message losses!! And the first message after a bunch of missed messages, is corrupted, namely it is truncated at the beginning. The handling of an invalid or incomplete messages (for example lacking a semicolon?) may be freezing netsend or netreceive?? Just a guess... ---------------------------------------------------------------------- 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_…

1 0

[ pure-data-Bugs-1891178 ] netsend/netreceive sometimes drop data
by SourceForge.net 17 Feb '08

17 Feb '08

Bugs item #1891178, was opened at 2008-02-11 15:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891178&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) >Summary: netsend/netreceive sometimes drop data Initial Comment: If you send a great enough number of messages throught a netsend immediately after the connection is established (for example triggered by the 1 output of netsend), the first messages are lost (and no error message issued). Netreceive receives some corrupted data, and then the last N messages sent. The attached patch illustrates the problem. ** TEST PROCEDURE: Click on the [connect ...( message box ** EXPECTED BEHAVIOUR: On PD output window the following should appear: CONNECTED: 1 DATA: bla bla 1 DATA: bla bla 2 DATA: bla bla 3 ... DATA: bla bla 1000 ** OBSERVED BEHAVIOUR The following output appears: CONNECTED: 1 DATA: 53 DATA: bla bla 954 DATA: bla bla 955 ... DATA: bla bla 1000 ==== Note that if you later click the [bng], all works as expected, i.e. no message is lost: message loss only seems to happen when too many messages are sent immediately after connection. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-17 17:11 Message: Logged In: YES user_id=1709568 Originator: YES fixed in 0.41-2 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-13 12:54 Message: Logged In: NO This DOESN'T ONLY happen when the burst of messages is sent immediately after connection. I have experienced message loss even sending a big burst of messages to a netsend that has been connected for a long time. I may send a burst of M messages and loose messages K through N with 0<K<N<M. In this case message N+1 is corrupted (its last part is received). Also, it seems that the burst doesn't need to be sent in 0 logical time to reproduce the bug. It seems it is sufficient to send enough messages in enough little time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891178&group_…

1 0

[ pure-data-Bugs-1893623 ] Tunring on DSP crashes PD
by SourceForge.net 17 Feb '08

17 Feb '08

Bugs item #1893623, was opened at 2008-02-14 15:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&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.41.0 >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: Tunring on DSP crashes PD Initial Comment: When turning on DSP for the N-th time, PD sometimes crashes. My empirical investigations lead me to think it happens when there are a big number of instances containing both [outlet]s and [outlet~]s I attach 3 zip files containing 3 tests. Each zip contains a main patch and the abstractions used within it. Testing on PD Vanilla 0.40, Windows XP, Intel core duo. *** A.ZIP *** - Open the main patch "test_crash_dsp3_new.pd" - Turn DSP on and off repeatedly. You can either do it manually or use the metro included in the patch. -> PD will crash around the 48-th time you turn DSP on. You don't need to switch "frenetically": I set the metro at a high rate to reach the crash in less time, but you can change it to [metro 1000] if you are willing to wait 96 seconds. *** B.ZIP *** - Open the main patch "dspcrash.pd" - Turn DSP on and off repeatedly. -> PD will crash around the 30-th time you turn DSP on; sometime much earlier, such as at the 8-th time. *** C.ZIP *** This is cleaner, but triggers the bug more unpredictably. - Open the main patch "main.pd" - Turn DSP on and off repeatedly -> PD will crash at some time when turning DSP on. It may crash at the 10-th time you turn it on, or you may need to turn it on/off more than 500 times. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-17 16:51 Message: Logged In: YES user_id=1709568 Originator: YES fixed in 0.41-2 so I close it ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:48 Message: Logged In: YES user_id=1709568 Originator: YES I increased the priority because it is a crasher. Am I allowed to do this? ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: C.zip ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: B.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&group_…

1 0

Re: [PD-dev] [PD] Problem in os x 10.5.1?
by David Plans Casal 16 Feb '08

16 Feb '08

Hello I have spent a bit of time with gdb and pd latest cvs, and I can now report that the problem with fork() and exec'ing causing CoreFoundation errors in mac os x is not, as Miller suspected, in t_tkcmd.c (circa line 423), but actually in s_inter.c, beginning line 1013, where: #ifdef UNISTD childpid = fork(); ...is called but execl() is not called until 1103. I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so... Any suggestions, anyone? David On 25 Jan 2008, at 09:44, David Plans Casal wrote: > > On 18 Jan 2008, at 17:55, Miller Puckette wrote: > >> ouch. The offending code is probably between the fork and exec >> in t_tkcmd.c (circa line 423). The only function call between them >> is >> a sprintf, wouldn't you know. Perhaps it will fix the problem if >> I do the sprintf before forking? I don't have 10.5.1 to test this >> on, >> so if it's easy for you to try that, I'd be grateful. > > Moving this thread to pd-dev, as I guess it belongs there. > > David > > >> cheers >> Miller >> >> >> On Fri, Jan 18, 2008 at 05:28:20PM +0000, David Plans Casal wrote: >>> Hey >>> >>> Has anyone noticed yet that trying to build CVS version on 10.5.1 >>> and >>> running gives: >>> >>> 18/01/2008 11:23:23 [0x0-0x96096].org.puredata[17406] The process >>> has >>> forked and you cannot use this CoreFoundation functionality safely. >>> You MUST exec(). >>> 18/01/2008 11:23:23 [0x0-0x96096].org.puredata[17406] Break on >>> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >>> () to debug. >>> >>> Then pd crashes after about 5 minutes. >>> >>> Actually, pd-extended seems to crash also, as well as Miller >>> releases >>> (stable and test). >>> >>> Anyone else? >>> >>> David >>> >>> _______________________________________________ >>> PD-list(a)iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

8 26

[ pure-data-Bugs-1894048 ] os x plist version
by SourceForge.net 14 Feb '08

14 Feb '08

Bugs item #1894048, was opened at 2008-02-14 13:25 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=1894048&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: os x plist version Initial Comment: fix version numbers for os x plist files. more details here: http://lists.puredata.info/pipermail/pd-list/2008-02/059627.html marius. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1894048&group_…

1 0

how to authenticate commits in SVN?
by Miller Puckette 14 Feb '08

14 Feb '08

Hi all, I'm trying to commit 0.41-1 to the svn repository, but can't figure out how to get authenticated. I checked the trunk out ala svn checkout https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/ and now when trying to commit I get a username challenge. In CVS I was using sourceforge's "ssl" authentification but can't figure out how to get SVN to use that. Do I have to check the sources out anew using a svnserve: or svn+ssh: URL? I'm not eager to try stuff at random since I'll have to redo all my changes if I check out from scratch. thanks Miller

7 9

[ pure-data-Bugs-1893623 ] Tunring on DSP crashes PD
by SourceForge.net 14 Feb '08

14 Feb '08

Bugs item #1893623, was opened at 2008-02-14 15:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&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.41.0 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: Tunring on DSP crashes PD Initial Comment: When turning on DSP for the N-th time, PD sometimes crashes. My empirical investigations lead me to think it happens when there are a big number of instances containing both [outlet]s and [outlet~]s I attach 3 zip files containing 3 tests. Each zip contains a main patch and the abstractions used within it. Testing on PD Vanilla 0.40, Windows XP, Intel core duo. *** A.ZIP *** - Open the main patch "test_crash_dsp3_new.pd" - Turn DSP on and off repeatedly. You can either do it manually or use the metro included in the patch. -> PD will crash around the 48-th time you turn DSP on. You don't need to switch "frenetically": I set the metro at a high rate to reach the crash in less time, but you can change it to [metro 1000] if you are willing to wait 96 seconds. *** B.ZIP *** - Open the main patch "dspcrash.pd" - Turn DSP on and off repeatedly. -> PD will crash around the 30-th time you turn DSP on; sometime much earlier, such as at the 8-th time. *** C.ZIP *** This is cleaner, but triggers the bug more unpredictably. - Open the main patch "main.pd" - Turn DSP on and off repeatedly -> PD will crash at some time when turning DSP on. It may crash at the 10-th time you turn it on, or you may need to turn it on/off more than 500 times. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:48 Message: Logged In: YES user_id=1709568 Originator: YES I increased the priority because it is a crasher. Am I allowed to do this? ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: C.zip ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: B.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&group_…

1 0

[ pure-data-Bugs-1893623 ] Tunring on DSP crashes PD
by SourceForge.net 14 Feb '08

14 Feb '08

Bugs item #1893623, was opened at 2008-02-14 15:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&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.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: Tunring on DSP crashes PD Initial Comment: When turning on DSP for the N-th time, PD sometimes crashes. My empirical investigations lead me to think it happens when there are a big number of instances containing both [outlet]s and [outlet~]s I attach 3 zip files containing 3 tests. Each zip contains a main patch and the abstractions used within it. Testing on PD Vanilla 0.40, Windows XP, Intel core duo. *** A.ZIP *** - Open the main patch "test_crash_dsp3_new.pd" - Turn DSP on and off repeatedly. You can either do it manually or use the metro included in the patch. -> PD will crash around the 48-th time you turn DSP on. You don't need to switch "frenetically": I set the metro at a high rate to reach the crash in less time, but you can change it to [metro 1000] if you are willing to wait 96 seconds. *** B.ZIP *** - Open the main patch "dspcrash.pd" - Turn DSP on and off repeatedly. -> PD will crash around the 30-th time you turn DSP on; sometime much earlier, such as at the 8-th time. *** C.ZIP *** This is cleaner, but triggers the bug more unpredictably. - Open the main patch "main.pd" - Turn DSP on and off repeatedly -> PD will crash at some time when turning DSP on. It may crash at the 10-th time you turn it on, or you may need to turn it on/off more than 500 times. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: C.zip ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: B.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&group_…

1 0

[ pure-data-Bugs-1893623 ] Tunring on DSP crashes PD
by SourceForge.net 14 Feb '08

14 Feb '08

Bugs item #1893623, was opened at 2008-02-14 15:45 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&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.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: Tunring on DSP crashes PD Initial Comment: When turning on DSP for the N-th time, PD sometimes crashes. My empirical investigations lead me to think it happens when there are a big number of instances containing both [outlet]s and [outlet~]s I attach 3 zip files containing 3 tests. Each zip contains a main patch and the abstractions used within it. Testing on PD Vanilla 0.40, Windows XP, Intel core duo. *** A.ZIP *** - Open the main patch "test_crash_dsp3_new.pd" - Turn DSP on and off repeatedly. You can either do it manually or use the metro included in the patch. -> PD will crash around the 48-th time you turn DSP on. You don't need to switch "frenetically": I set the metro at a high rate to reach the crash in less time, but you can change it to [metro 1000] if you are willing to wait 96 seconds. *** B.ZIP *** - Open the main patch "dspcrash.pd" - Turn DSP on and off repeatedly. -> PD will crash around the 30-th time you turn DSP on; sometime much earlier, such as at the 8-th time. *** C.ZIP *** This is cleaner, but triggers the bug more unpredictably. - Open the main patch "main.pd" - Turn DSP on and off repeatedly -> PD will crash at some time when turning DSP on. It may crash at the 10-th time you turn it on, or you may need to turn it on/off more than 500 times. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2008-02-14 15:47 Message: Logged In: YES user_id=1709568 Originator: YES File Added: B.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev February 2008