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_…
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_…
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
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_…
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
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_…
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_…
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_…
Bugs item #1893620, was opened at 2008-02-14 15:42
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893620&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: turning on DSP crashes PD (at least in Windows)
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:46
Message:
Logged In: YES
user_id=1709568
Originator: NO
PLEASE DELETE THIS BUG.
It was me who submitted it, but I didn't realize I wasn't logged in so noy
I can't add files!!!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893620&group_…
Bugs item #1893623, was opened at 2008-02-14 15:45
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=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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1893623&group_…