<div dir="ltr">Sorry, I thought I had fixed this in the last update. I swear it was working for me, but then... that reported bug came back :) The object still works fine for me in my use cases. Anyway, I'll give it another go in the next update. If I fail miserably I'll ask for help. I just have other plans for the moment though...<div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-23 19:09 GMT-03:00 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey all<br>
<br>
Not only by creating 1020 instances of [else/dir] you can crash Pd, but<br>
also by sending it a 337 'reset, open .' messages. I guess the reason<br>
is the same: [else/dir] is leaking file handles. <br>
<br>
It appears I tried  [else/dir] for the similar reasons as you, Liam. I<br>
am also using [ggee/getdir] and [moocow/readdir] now and thought about<br>
reducing dependencies by switching to else. It turns out I can't switch<br>
yet.<br>
<br>
Roman<br>
<br>
<br>
<br>
On Sun, 2018-05-27 at 19:26 +0000, Liam Goodacre wrote:<br>
> OK, I've just spent several hours on this, testing upwards of 200,000<br>
> parallel abstractions and crashing my computer almost as many times.<br>
> But I managed to figure it out.<br>
> <br>
> (Most of) you will be relieved to hear that the problem does not<br>
> originate with the PD core, but with externals, as IOhannes<br>
> suggested. Alex will not be relieved to hear that the culprit is<br>
> [else/dir]. It seems that the 1019th instance of this object crashes<br>
> PD! How strange.<br>
> <br>
> I'm filing a bug report on git and moving on with my life.<br>
> <br>
> Liam<br>
> <br>
> <br>
> From: Pd-list <<a href="mailto:pd-list-bounces@lists.iem.at">pd-list-bounces@lists.iem.at</a>> on behalf of Liam<br>
> Goodacre <<a href="mailto:liamg_uw@hotmail.com">liamg_uw@hotmail.com</a>><br>
> Sent: 22 May 2018 05:36<br>
> To: <a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a><br>
> Subject: Re: [PD] "too many open files" error in 0.48.1<br>
>  <br>
> Thank you for the input. It will be a few days before I can do any<br>
> serious testing, but I can answer some of your questions now.<br>
> <br>
> IOhannes: yes, I upgraded PD, my externals, and my OS, all at the<br>
> same time. I'll try it out with various different versions of the<br>
> same and let you know what happens. But just as a heads-up, it's<br>
> quite possible that I am trying to load more than 10,000 abstractions<br>
> at once. Quite difficult to count them though!<br>
> <br>
> If neither the externals nor the OS turn out to be the problem,<br>
> I'll try to come up with a simple test case and get back to you.<br>
> From: Pd-list <<a href="mailto:pd-list-bounces@lists.iem.at">pd-list-bounces@lists.iem.at</a>> on behalf of IOhannes m<br>
> zmölnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>><br>
> Sent: 21 May 2018 20:50<br>
> To: <a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a><br>
> Subject: Re: [PD] "too many open files" error in 0.48.1<br>
>  <br>
> On 05/21/2018 09:37 PM, ub@xdv wrote:<br>
> > On 21.05.2018 20:54, Claude Heiland-Allen wrote:<br>
> >><br>
> >><br>
> >> On 21/05/18 19:35, ub@xdv wrote:<br>
> >>> hello,<br>
> >>><br>
> >>> On 20.05.2018 06:50, Liam Goodacre wrote:<br>
> >>>> In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD<br>
> refuses to<br>
> >>>> open patches or create any more abstractions for me. I get an<br>
> error<br>
> >>>> message saying "too many open files". Granted I have a lot open,<br>
> but<br>
> >>>> this is a serious problem as it means I can't access all of my<br>
> old<br>
> >>>> performances. They worked fine in 0.47.<br>
> >>>><br>
> >>>> Any ideas?<br>
> >>> this is not really a problem with pd<br>
> >><br>
> >> I disagree. The most common cause of "too many open files" is a<br>
> bug in<br>
> >> closing files properly, <br>
> <br>
> intuitively i would agree.<br>
> <br>
> > possible. never occured to me. is it in the issue tracker?<br>
> <br>
> no (afaik). it hasn't been reported before.<br>
> <br>
> > <br>
> >> because 1024 simultaneously-open files should be<br>
> >> enough for most use cases.definitely, but when someone says<br>
> "Granted I have a lot open", that<br>
> > could be an understatement. or a regression of some sort.<br>
> <br>
> so i did a test run, with some heavily embedded abstraction, that is<br>
> loaded a total of 10000 times.<br>
> $ ulimit -Sn<br>
> 1024<br>
> $ valgrind --track-fds=yes pd -noprefs -oss -nosound -nomidi -nrt<br>
> -stderr -open test.pd<br>
> [...]<br>
> ==29030== FILE DESCRIPTORS: 3 open at exit.<br>
> ==29030== Open file descriptor 2: /dev/pts/12<br>
> ==29030==    <inherited from parent><br>
> ==29030==<br>
> ==29030== Open file descriptor 1: /dev/pts/12<br>
> ==29030==    <inherited from parent><br>
> ==29030==<br>
> ==29030== Open file descriptor 0: /dev/pts/12<br>
> ==29030==    <inherited from parent><br>
> ==29030==<br>
> [...]<br>
> $<br>
> <br>
> so there seems to be neither a temporary file-handle leak (because my<br>
> 10000 abstractions load just fine) nor an absolute file-handle leak<br>
> (since the only handles that are left open by the program are stdin,<br>
> stdout, stderr)<br>
> <br>
> <br>
> so i guess there must be something wrong with the patch.<br>
> <br>
> @liam are there any externals in use? did you upgrade the entire<br>
> system<br>
> or just Pd? when using an older version of Pd, does the problem<br>
> persist?<br>
> <br>
> gfmtdsar<br>
> IOhannes<br>
> <br>
> <br>
> > <br>
> > <br>
> >><br>
> >><br>
> >> Claude<br>
> >><br>
> >>> , but with your shell- or system<br>
> >>> configuration limiting the number of open file descriptors.<br>
> >>><br>
> >>> check your current shell-limit with<br>
> >>> ulimit -Sn<br>
> >>> -S is for soft limit (you can lower, but not raise, the hard<br>
> limit).<br>
> >>> raise the limit in your shell with<br>
> >>> ulimit -n 65536<br>
> >>> start pd from that shell and see if the situation improves.<br>
> >>><br>
> >>> if that doesn't help, you can check the kernel limits with<br>
> >>> cat /proc/sys/fs/file-nr<br>
> >>> which returns 3 numbers, the first of which is the number of open<br>
> files,<br>
> >>> the last of which is the limit.<br>
> >>><br>
> >>> increase the value of "nofile" in  /etc/security/limits.conf<br>
> >>> do<br>
> >>> sudo sysctl -p<br>
> >>><br>
> >>> additional steps are required to make these settings permanent,<br>
> the<br>
> >>> ulimit -n 65536 would have to go into your .bashrc so it's<br>
> executed at<br>
> >>> system startup. if you normally start pd from your GUI you'd have<br>
> to<br>
> >>> restart your system (actually just xorg) so your master shell<br>
> knows<br>
> >>> about the new value. there's other ways, one of which would be to<br>
> start<br>
> >>> pd from a wrapper script, or probably gnome provides that sort of<br>
> >>> environmental setup for it's program shortcuts.<br>
> >>><br>
> >>> there's more information<br>
> >>> -<br>
> >>> <a href="https://askubuntu.com/questions/162229/how-do-i-increase-the-open" rel="noreferrer" target="_blank">https://askubuntu.com/<wbr>questions/162229/how-do-i-<wbr>increase-the-open</a><br>
> -files-limit-for-a-non-root-<wbr>user<br>
> >>><br>
> >>> -<br>
> >>> <a href="https://unix.stackexchange.com/questions/29577/ulimit-difference-" rel="noreferrer" target="_blank">https://unix.stackexchange.<wbr>com/questions/29577/ulimit-<wbr>difference-</a><br>
> between-hard-and-soft-limits<br>
> >>><br>
> >>><br>
> >>> hope that helps ... cheers,<br>
> >>> ub<br>
> >>><br>
> >>>> Liam<br>
> >>>><br>
> >>>><br>
> >>>> ______________________________<wbr>_________________<br>
> >>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> >>>> UNSUBSCRIBE and account-management -><br>
> >>>> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
> >>>><br>
> >>><br>
> >>> ______________________________<wbr>_________________<br>
> >>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> >>> UNSUBSCRIBE and account-management -><br>
> >>> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
> > <br>
> > <br>
> > ______________________________<wbr>_________________<br>
> > <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> > UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/l" rel="noreferrer" target="_blank">https://lists.puredata.info/l</a><br>
> istinfo/pd-list<br>
> > <br>
> <br>
> <br>
> ______________________________<wbr>_________________<br>
> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/lis" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>lis</a><br>
> tinfo/pd-list<br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div>