On 05/21/2018 09:37 PM, ub@xdv wrote:
On 21.05.2018 20:54, Claude Heiland-Allen wrote:
On 21/05/18 19:35, ub@xdv wrote:
hello,
On 20.05.2018 06:50, Liam Goodacre wrote:
In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to open patches or create any more abstractions for me. I get an error message saying "too many open files". Granted I have a lot open, but this is a serious problem as it means I can't access all of my old performances. They worked fine in 0.47.
Any ideas?
this is not really a problem with pd
I disagree. The most common cause of "too many open files" is a bug in closing files properly,
intuitively i would agree.
possible. never occured to me. is it in the issue tracker?
no (afaik). it hasn't been reported before.
because 1024 simultaneously-open files should be enough for most use cases.definitely, but when someone says "Granted I have a lot open", that
could be an understatement. or a regression of some sort.
so i did a test run, with some heavily embedded abstraction, that is loaded a total of 10000 times. $ ulimit -Sn 1024 $ valgrind --track-fds=yes pd -noprefs -oss -nosound -nomidi -nrt -stderr -open test.pd [...] ==29030== FILE DESCRIPTORS: 3 open at exit. ==29030== Open file descriptor 2: /dev/pts/12 ==29030== <inherited from parent> ==29030== ==29030== Open file descriptor 1: /dev/pts/12 ==29030== <inherited from parent> ==29030== ==29030== Open file descriptor 0: /dev/pts/12 ==29030== <inherited from parent> ==29030== [...] $
so there seems to be neither a temporary file-handle leak (because my 10000 abstractions load just fine) nor an absolute file-handle leak (since the only handles that are left open by the program are stdin, stdout, stderr)
so i guess there must be something wrong with the patch.
@liam are there any externals in use? did you upgrade the entire system or just Pd? when using an older version of Pd, does the problem persist?
gfmtdsar IOhannes
Claude
, but with your shell- or system configuration limiting the number of open file descriptors.
check your current shell-limit with ulimit -Sn -S is for soft limit (you can lower, but not raise, the hard limit). raise the limit in your shell with ulimit -n 65536 start pd from that shell and see if the situation improves.
if that doesn't help, you can check the kernel limits with cat /proc/sys/fs/file-nr which returns 3 numbers, the first of which is the number of open files, the last of which is the limit.
increase the value of "nofile" in /etc/security/limits.conf do sudo sysctl -p
additional steps are required to make these settings permanent, the ulimit -n 65536 would have to go into your .bashrc so it's executed at system startup. if you normally start pd from your GUI you'd have to restart your system (actually just xorg) so your master shell knows about the new value. there's other ways, one of which would be to start pd from a wrapper script, or probably gnome provides that sort of environmental setup for it's program shortcuts.
there's more information
https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limi...
https://unix.stackexchange.com/questions/29577/ulimit-difference-between-har...
hope that helps ... cheers, ub
Liam
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list