IOhannes m zmoelnig wrote:
>
> the svn client installed on the build-machine (/sw/bin/svn) is somewhat
> outdated (1.4.4) and refuses to "svn update" the sandbox.
this seems to be a common problem on more of the build machines (e.g. i
just noticed it on the ubuntu-hardy-lts-i386)
for me this makes working on these machines a bit strange: you fix the
code, login to the build machine, try to "svn update" (or rather: "svn
info" or "svnversion" to see which revision was actually used) and get
"svn: This client is too old to work with working copy"
what?
i guess, that for performance reasons (the sf repositories often suck)
the repository is pulled only to a central machine and then distributed
via rsync to the various build hosts.
however, i haven't found any documentation on this.
it would be nice if the tools installed on the build hosts would be able
to cope with the repository.
if this is too much hazzle (e.g. setting up a proxy, or whatever), could
somebody learned please document e.g. on
http://puredata.info/docs/developer/PdLab (or somewhere linked from
there; or in the nice splashscreen on the build-machines) what is to be
expected and what not?
the workaround that does work (it seems), is to do another checkout with
the system's own svn and work in this sandbox.
i usually do this only on 2nd choice (in order to save bandwidth).
i guess it's just a matter of knowing.
fbm,asdr
IOhannes
Hey all,
In case you didn't already see it, we now have a Macbook Pro with a
dead screen set up as a 10.4/Intel build server. Thanks for Greg Pond/
Sewanee for the donation of said Macbook.
http://puredata.info/docs/developer/Macosx104I386
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman
Bugs item #2724318, was opened at 2009-03-31 22:23
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2724318&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Miller Puckette (millerpuckette)
Summary: 'pd -alsa -send "; pd dsp 1"' fails with -nogui
Initial Comment:
$ pd -alsa -send "; pd dsp 1"
works fine
$ pd -alsa -nogui -send "; pd dsp 1"
snd_pcm_open (output): Device or resource busy
if i send to a custom receiver and delay the message by 100ms it seems to work ok, but still, not perfect
at a guess there's a race condition somewhere, and using the gui slows it down enough to work? just a guess though
tested on GNU/Linux/Debian/Lenny/pure:dyne with pd-0.41
may also affect other sound APIs, but I haven't tested with anything other than ALSA
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-11-30 11:21
Message:
Confirmed on Debian/lenny/i386 running Pd-vanilla 0.41.4 and Pd-extended
0.41.4 and 0.42.5.
----------------------------------------------------------------------
Comment By: Cesar Mauri-Loba (cmauri)
Date: 2009-08-24 11:21
Message:
Confirmed in pd 0.42-5 under WinXP SP3. These are the error messages:
Error number -9985 opening portaudio stream
Error message: Device unavailable
As a workaround I've added a delay after the loadbang that enables the
dsp.
----------------------------------------------------------------------
Comment By: Dan Wilcox (danomatika)
Date: 2009-06-15 06:51
Message:
Again in Ubuntu Jaunty,
Running the same startup patch which loadbangs "pd dsp 1" in pd-extended
0.40.3 with "-rt" yields the same problem. I suppose in realtime mode, pd
runs too fast to avoid the race condition.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-15 06:47
Message:
Confirmed in pd-extended 0.41.4 on Ubuntu Jaunty.
Cannot open the soundcard when starting pd with "pd -nogui -alsa -audiodev
4 ~/StartupPatch.pd" where "StartupPatch.pd" loadbangs a "pd dsp 1"
message:
snd_pcm_open (input): Device or resource busy
snd_pcm_open (output): Device or resource busy
Using jack, "-jack -channels 2" connects ok. I have not not tried oss.
Doing the same on pd-extended 0.40.3 works fine.
Well, at least I can just delay the dsp switch for now to make it work.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2009-04-02 10:22
Message:
oh forgot to say:
OSS:
/dev/dsp (writeonly): Device or resource busy
/dev/dsp (readonly): Device or resource busy
with jack it seems to work fine (though i often have other problems with
jack, so i don't know how reliable this is)
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2009-04-02 10:20
Message:
confirmed with Pd-0.42.4 (debian lenny/squeeze; x86)
however i thought the proper way to specify the send-message was "pd dsp
1" (without the leading semicolon)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2724318&group_…
Bugs item #2838114, was opened at 2009-08-15 12:33
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&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: None
>Status: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: zexy fwriteln buffer overflow
Initial Comment:
The buffer for the prefix is too small.
gcc -I. -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD -I/usr/src/pd/src -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall -O2 -c -o fwriteln.o fwriteln.c
In file included from /usr/include/string.h:640,
from fwriteln.c:26:
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:233:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:236:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
Line 195: char prefix[2]="%";
Line 233: strcpy(prefix,"%-");
Line 236: strcpy(prefix,"%+");
The strcpy will copy an additional '\0' byte which will overflow the buffer.
Suggested fix: increase the prefix buffer size
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2009-11-30 10:03
Message:
submitted with r18215
thanks
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_…
Bugs item #2838114, was opened at 2009-08-15 12:33
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
>Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: zexy fwriteln buffer overflow
Initial Comment:
The buffer for the prefix is too small.
gcc -I. -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD -I/usr/src/pd/src -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall -O2 -c -o fwriteln.o fwriteln.c
In file included from /usr/include/string.h:640,
from fwriteln.c:26:
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:233:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:236:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
Line 195: char prefix[2]="%";
Line 233: strcpy(prefix,"%-");
Line 236: strcpy(prefix,"%+");
The strcpy will copy an additional '\0' byte which will overflow the buffer.
Suggested fix: increase the prefix buffer size
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 20:09
Message:
Hi Martin
Thanks a lot for providing a fix so quickly.
Things looks very good. I was putting the tcpserver based netpd-server
under the heaviest load i can get, which is limited by the bandwidth of my
home internet connection. While constantly sending messages with ~50 kB/s
bandwidth up to the server and ~350kB/s receiving from it, all messages
come through intact. It is stable also when connecting and disconnecting a
lot of clients at the same time, while constantly broadcasting messages.
The cpu usage is *much* lower than with the select() based tcpserver; with
the bandwidth load mentioned above, it is about 12%, whereas it reached
100% with much less load before.
Thanks again for all your work spent on this issue.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 17:50
Message:
oops, thought I was logged in...anyhow I'll try it on a linux box tomorrow.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-29 17:47
Message:
It was probably the handles that reached a limit, the threads disappear
after the data has been sent but their handles were not being cleaned up.
Now the threads are created in the detached state so their handles are
freed on exit. On WinXP the handles and threads are fairly constant now.
I'll leave the patch running to see if it ever hangs, but t seems to be
working OK here.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-28 19:20
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 12:50
Message:
oops, thought I was logged in...anyhow I'll try it on a linux box tomorrow.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-29 12:47
Message:
It was probably the handles that reached a limit, the threads disappear
after the data has been sent but their handles were not being cleaned up.
Now the threads are created in the detached state so their handles are
freed on exit. On WinXP the handles and threads are fairly constant now.
I'll leave the patch running to see if it ever hangs, but t seems to be
working OK here.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 09:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 01:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-28 19:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-29 17:47
Message:
It was probably the handles that reached a limit, the threads disappear
after the data has been sent but their handles were not being cleaned up.
Now the threads are created in the detached state so their handles are
freed on exit. On WinXP the handles and threads are fairly constant now.
I'll leave the patch running to see if it ever hangs, but t seems to be
working OK here.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-28 19:20
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 01:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-28 19:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…