bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 4095 bytes --]

Hello,

I have a large emacs desktop file (600+ buffers at the moment). Emacs
24.5 would open all the buffers just fine, but 25.0.91 (and 90)
apparently don't close the file after reading the buffer (or maybe it's
part of the new kqueue stuff?). By default OS X limits the number of
file descriptors per process to 256. So trying to open my large desktop
file gets it into a stuck state where it cannot open any more files
after it loads the first 240ish buffers.

This seems to me like a regression from 24.5 to 25.1.

-David


In GNU Emacs 25.0.91.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21
Version 10.9.5 (Build 13F1603))
 of 2016-02-13 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: en_US
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  global-flycheck-mode: t
  auto-insert-mode: t
  save-place-mode: t
  show-paren-mode: t
  global-diff-hl-mode: t
  diff-auto-refine-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading delsel...done
Loading autorevert...done
Loading diff-hl...done
Loading undo-tree...done
Loading gnus...done
Loading paren...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug flycheck find-func rx subr-x seq
byte-opt gv bytecomp byte-compile cconv cl-extra dash
david-custom-emacs-setup advice editorconfig commit-patch-buffer
log-edit message sendmail dired format-spec rfc822 mml mml-sec epg
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader ring pcvs-util add-log
david-headers autoinsert ginel-string david-keys david-movement
david-coding-style saveplace calmer-forest-theme paren gnus gnus-ems
nnheader gnus-util mail-utils mm-util help-fns help-mode mail-prsvr
wid-edit undo-tree diff diff-hl edmacro kmacro smartrep vc-dir ewoc vc
cl-loaddefs pcase cl-lib vc-dispatcher diff-mode easy-mmode autorevert
filenotify delsel cus-start cus-load benchmark finder-inf
ack-and-a-half-autoloads go-mode-autoloads magithub-autoloads
mode-compile-autoloads nav-autoloads rainbow-mode-autoloads
slime-autoloads svg-clock-autoloads info package easymenu epg-config
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 347585 16892)
 (symbols 48 27326 1)
 (miscs 40 109 303)
 (strings 32 44145 10694)
 (string-bytes 1 1249905)
 (vectors 16 48605)
 (vector-slots 8 1487708 148374)
 (floats 8 246 26)
 (intervals 56 329 94)
 (buffers 976 12))


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3819 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

David Caldwell <david@porkrind.org> writes:

> Hello,

Hi David,

> I have a large emacs desktop file (600+ buffers at the moment). Emacs
> 24.5 would open all the buffers just fine, but 25.0.91 (and 90)
> apparently don't close the file after reading the buffer (or maybe it's
> part of the new kqueue stuff?). By default OS X limits the number of
> file descriptors per process to 256. So trying to open my large desktop
> file gets it into a stuck state where it cannot open any more files
> after it loads the first 240ish buffers.

You are using "global-auto-revert-mode: t". kqueue does not support a
directory monitor, therefore it starts a new file notification monitor
for every single file, indeed.

I believe it is questionable to run auto-revert-mode for so many files,
but that's your choice. In order to suppress kqueue running for
auto-revert-mode, you shall set auto-revert-use-notify to nil.

Maybe there are means in OS X to increase the number of file descriptors
for Emacs, don't know. I don't use OS X.

I will add a note to the Emacs manual.

> -David

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On 2/26/16 12:34 AM, Michael Albinus wrote:
> David Caldwell <david@porkrind.org> writes:
>> I have a large emacs desktop file (600+ buffers at the moment). Emacs
>> 24.5 would open all the buffers just fine, but 25.0.91 (and 90)
>> apparently don't close the file after reading the buffer (or maybe it's
>> part of the new kqueue stuff?). By default OS X limits the number of
>> file descriptors per process to 256. So trying to open my large desktop
>> file gets it into a stuck state where it cannot open any more files
>> after it loads the first 240ish buffers.
>
> You are using "global-auto-revert-mode: t". kqueue does not support a
> directory monitor, therefore it starts a new file notification monitor
> for every single file, indeed.

Ah, I see. Maybe the FSEvents API[1] would be better in this case?

> I believe it is questionable to run auto-revert-mode for so many
> files,

> but that's your choice.=20

It's just stat()s, right? Those are really fast, especially on my ssd.
At any rate, I've never noticed any slowdown. I guess I always assumed
it would check only for buffers I was displaying, rather than ones in
the background (because why would I care if a buffer I couldn't see had
stale data in it?).

> In order to suppress kqueue running for auto-revert-mode, you shall 
> set auto-revert-use-notify to nil.

Thanks! That indeed does the trick. I'm back to 24.5 numbers of fds open.

> Maybe there are means in OS X to increase the number of file
> descriptors for Emacs, don't know. I don't use OS X.

`ulimit -u 10000` was my temporary work-around, but I had to remember to
do it every time I booted or emacs would hose itself (I don't think I
ever successfully remembered).

> I will add a note to the Emacs manual.

Thanks.

-David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3819 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Nicolas Richard]

David Caldwell <david@porkrind.org> writes:
>                                               I guess I always assumed
> it would check only for buffers I was displaying, rather than ones in
> the background (because why would I care if a buffer I couldn't see had
> stale data in it?).

You could be using e.g. append-to-buffer (I do that on files tracked by
owncloud).

-- 
Nicolas

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 26 Feb 2016 09:34:50 +0100
> Cc: 22814@debbugs.gnu.org
> 
> You are using "global-auto-revert-mode: t". kqueue does not support a
> directory monitor, therefore it starts a new file notification monitor
> for every single file, indeed.
> 
> I believe it is questionable to run auto-revert-mode for so many files,
> but that's your choice. In order to suppress kqueue running for
> auto-revert-mode, you shall set auto-revert-use-notify to nil.
> 
> Maybe there are means in OS X to increase the number of file descriptors
> for Emacs, don't know. I don't use OS X.
> 
> I will add a note to the Emacs manual.

I suggest adding this to etc/PROBLEMS as well.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Version: 25.1

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Date: Fri, 26 Feb 2016 09:34:50 +0100
>> Cc: 22814@debbugs.gnu.org
>> 
>> You are using "global-auto-revert-mode: t". kqueue does not support a
>> directory monitor, therefore it starts a new file notification monitor
>> for every single file, indeed.
>> 
>> I believe it is questionable to run auto-revert-mode for so many files,
>> but that's your choice. In order to suppress kqueue running for
>> auto-revert-mode, you shall set auto-revert-use-notify to nil.
>> 
>> Maybe there are means in OS X to increase the number of file descriptors
>> for Emacs, don't know. I don't use OS X.
>> 
>> I will add a note to the Emacs manual.
>
> I suggest adding this to etc/PROBLEMS as well.

Done. Closing the bug.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: David Caldwell <david@porkrind.org>
> Date: Thu, 25 Feb 2016 22:18:13 -0800
> 
> I have a large emacs desktop file (600+ buffers at the moment). Emacs
> 24.5 would open all the buffers just fine, but 25.0.91 (and 90)
> apparently don't close the file after reading the buffer (or maybe it's
> part of the new kqueue stuff?). By default OS X limits the number of
> file descriptors per process to 256. So trying to open my large desktop
> file gets it into a stuck state where it cannot open any more files
> after it loads the first 240ish buffers.
> 
> This seems to me like a regression from 24.5 to 25.1.

Do you have global auto-revert turned on?  Or just auto-revert, but in
many buffers?

More generally, if you start "emacs -Q" and then visit all those
files, does that run into the same problem after 240-something files?

Thanks.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Hi!

>>> You are using "global-auto-revert-mode: t". kqueue does not support a
>>> directory monitor, therefore it starts a new file notification monitor
>>> for every single file, indeed.
>>>
>>> I believe it is questionable to run auto-revert-mode for so many files,
>>> but that's your choice. In order to suppress kqueue running for
>>> auto-revert-mode, you shall set auto-revert-use-notify to nil.
>>>
>>> Maybe there are means in OS X to increase the number of file descriptors
>>> for Emacs, don't know. I don't use OS X.
>>>
>>> I will add a note to the Emacs manual.
>>
>> I suggest adding this to etc/PROBLEMS as well.
>
> Done. Closing the bug.

Unfortunately, I don't think this is enough.

If Emacs hangs because the file notification system runs out of resources
(file descriptors or processes), it should detect this by itself and revert
to other, safer, methods (e.g. the timer-based system).

One simple way to handle this is to define a variable with "max" number of
files the notification system can handle. We can set this to, say, 200 on
OS X and unlimited on other systems.

I would suggest leaving the bug open until someone figures out how to
increase the resources in OS X, or the file notification system can handle
that it runs out of resources.

    -- Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 1810 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

> Hi!

Hi Anders,

>> Done. Closing the bug.
>
> Unfortunately, I don't think this is enough.

I've reopened it, until we get an agreement.

> If Emacs hangs because the file notification system runs out of
> resources (file descriptors or processes), it should detect this by
> itself and revert to other, safer, methods (e.g. the timer-based
> system).

A general support for polling in filenotify.el is not foreseen, too much
effort. But I believe, in the auto-revert case Emacs works already this
way. When file-notify-add-watch returns nil, auto-revert falls back to
polling (to be tested, I'll I add a test).

> One simple way to handle this is to define a variable with "max"
> number of files the notification system can handle. We can set this
> to, say, 200 on OS X and unlimited on other systems.

Would be possible, yes. I would prefer to set the limit to a system
related value. Does there exist a portable way to detect, how many file
descriptors / processes Emacs is able to consume?

> I would suggest leaving the bug open until someone figures out how to
> increase the resources in OS X, or the file notification system can
> handle that it runs out of resources.

Done, see above. I don't know whether we want to increase the resources
silently for Emacs.

> -- Anders Lindgren

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 27 Feb 2016 09:00:14 +0100
> Cc: 22814@debbugs.gnu.org
> 
> > One simple way to handle this is to define a variable with "max"
> > number of files the notification system can handle. We can set this
> > to, say, 200 on OS X and unlimited on other systems.
> 
> Would be possible, yes. I would prefer to set the limit to a system
> related value. Does there exist a portable way to detect, how many file
> descriptors / processes Emacs is able to consume?

Not portably, AFAIK.  Also, different implementations use different
resources for receiving file notifications.  For example, w32notify
uses one handle and one thread per watched file/directory.  The number
of handles a process can have on Windows is very large, and the
theoretical max number of threads is 32K, but both are limited by the
resources already consumed by the Emacs process.  So determining the
practical maximum at any given point will require a non-trivial
function.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > One simple way to handle this is to define a variable with "max"
>> > number of files the notification system can handle. We can set this
>> > to, say, 200 on OS X and unlimited on other systems.
>>
>> Would be possible, yes. I would prefer to set the limit to a system
>> related value. Does there exist a portable way to detect, how many file
>> descriptors / processes Emacs is able to consume?
>
> Not portably, AFAIK.

On POSIX systems, we could propagate the result of

if !(getrlimit (RLIMIT_NOFILE, &rlim))
   return make_number (rlim.rlim_cur);
else
   return Qnil;

Maybe we add a function like `<library>-max-descriptors' to the
libraries. Or maybe not, and the backends check this themselves, and
cease to work when reaching an internal limit. Such an internal limit
could be half the number of soft RLIMIT_NOFILE on POSIX systems, for
example.

> Also, different implementations use different
> resources for receiving file notifications.  For example, w32notify
> uses one handle and one thread per watched file/directory.  The number
> of handles a process can have on Windows is very large, and the
> theoretical max number of threads is 32K, but both are limited by the
> resources already consumed by the Emacs process.  So determining the
> practical maximum at any given point will require a non-trivial
> function.

There must be different scenarios for different file notification
libraries. But using RLIMIT_NOFILE as basis when possible gives us
better results on systems like OS X and FreeBSD, which both use kqueue,
but provide different ressource limits.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Hi!

I just gave this some thought (without knowing anything about the kqueue
notifications).

I don't think the problem is what kqueue does when it run out of file
descriptors, but how the rest of the Emacs process acts when this happens.
For example, can it even read and write files? Can subprocesses be started?

The question, then, is how should the kqueue system work so that it doesn't
run Emacs out of file descriptors? For example, if it would be possible to
check how many are available, it could stop when there are, say, 50
remaining. Effectively, this would give a user 200 files that are
auto-reverted using the notification system, and the rest would be handled
by the old timer system.

    -- Anders

On Sat, Feb 27, 2016 at 2:26 PM, Michael Albinus <michael.albinus@gmx.de>
wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > One simple way to handle this is to define a variable with "max"
> >> > number of files the notification system can handle. We can set this
> >> > to, say, 200 on OS X and unlimited on other systems.
> >>
> >> Would be possible, yes. I would prefer to set the limit to a system
> >> related value. Does there exist a portable way to detect, how many file
> >> descriptors / processes Emacs is able to consume?
> >
> > Not portably, AFAIK.
>
> On POSIX systems, we could propagate the result of
>
> if !(getrlimit (RLIMIT_NOFILE, &rlim))
>    return make_number (rlim.rlim_cur);
> else
>    return Qnil;
>
> Maybe we add a function like `<library>-max-descriptors' to the
> libraries. Or maybe not, and the backends check this themselves, and
> cease to work when reaching an internal limit. Such an internal limit
> could be half the number of soft RLIMIT_NOFILE on POSIX systems, for
> example.
>
> > Also, different implementations use different
> > resources for receiving file notifications.  For example, w32notify
> > uses one handle and one thread per watched file/directory.  The number
> > of handles a process can have on Windows is very large, and the
> > theoretical max number of threads is 32K, but both are limited by the
> > resources already consumed by the Emacs process.  So determining the
> > practical maximum at any given point will require a non-trivial
> > function.
>
> There must be different scenarios for different file notification
> libraries. But using RLIMIT_NOFILE as basis when possible gives us
> better results on systems like OS X and FreeBSD, which both use kqueue,
> but provide different ressource limits.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 3248 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

> Hi!

Hi Anders,

> I don't think the problem is what kqueue does when it run out of file
> descriptors, but how the rest of the Emacs process acts when this
> happens. For example, can it even read and write files? Can
> subprocesses be started?
>
> The question, then, is how should the kqueue system work so that it
> doesn't run Emacs out of file descriptors? For example, if it would be
> possible to check how many are available, it could stop when there
> are, say, 50 remaining. Effectively, this would give a user 200 files
> that are auto-reverted using the notification system, and the rest
> would be handled by the old timer system.

Something like this I plan to implement in kqueue.c and inotify.c. For
gfilenotify.c this shouldn't be necessary, it switches to polling
already when necessary. But maybe I retest.

Remote backends (inotifywait, gvfs-monitor-dir) are different, here it
isn't the number of file descriptors but the number of processes allowed
to start, which counts. I'll give it some thinking as well. Tramp is
written in Lisp, the checks will be harder to perform. Maybe I'll
introduce a hardcoded limit of possible file notification watches.

w32notify.c I cannot touch. Hopefully, somebody else takes the ball.

All of this shall go into the master, I believe. For the emacs-25 branch
we know what to do, described somewhere earlier in this bug's messages.

> -- Anders

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 20:12:18 +0100
> 
> w32notify.c I cannot touch. Hopefully, somebody else takes the ball.

When something like that happens in w32notify, it will return an
error, which needs to be handled.

> All of this shall go into the master, I believe. For the emacs-25 branch
> we know what to do, described somewhere earlier in this bug's messages.

How about defaulting to auto-revert-use-notify = nil when
global-auto-revert-mode is turned on?

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> w32notify.c I cannot touch. Hopefully, somebody else takes the ball.
>
> When something like that happens in w32notify, it will return an
> error, which needs to be handled.

I meant that maybe a similar internal limit could be added, in order to
keep Emacs running normal, not being at its upper limits.

>> All of this shall go into the master, I believe. For the emacs-25 branch
>> we know what to do, described somewhere earlier in this bug's messages.
>
> How about defaulting to auto-revert-use-notify = nil when
> global-auto-revert-mode is turned on?

I don't know whether it is the majority of users, who enable
global-auto-revert-mode *and* work with hundreds of buffers. So far,
there is one report about.

And such power users are more likely to know how to disable file
notification then.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 20:33:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> w32notify.c I cannot touch. Hopefully, somebody else takes the ball.
> >
> > When something like that happens in w32notify, it will return an
> > error, which needs to be handled.
> 
> I meant that maybe a similar internal limit could be added, in order to
> keep Emacs running normal, not being at its upper limits.

It's not a fixed limit, alas.  The number of threads we can start is
limited by available memory (because each thread uses some for its
stack), and the amount of available memory depends on how much Emacs
itself uses.

> > How about defaulting to auto-revert-use-notify = nil when
> > global-auto-revert-mode is turned on?
> 
> I don't know whether it is the majority of users, who enable
> global-auto-revert-mode *and* work with hundreds of buffers. So far,
> there is one report about.
> 
> And such power users are more likely to know how to disable file
> notification then.

Perhaps we shouldn't wait for a flood of bug reports, and do this
proactively?

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> I meant that maybe a similar internal limit could be added, in order to
>> keep Emacs running normal, not being at its upper limits.
>
> It's not a fixed limit, alas.  The number of threads we can start is
> limited by available memory (because each thread uses some for its
> stack), and the amount of available memory depends on how much Emacs
> itself uses.

In this case one could use a hard-coded limit. 512 watches, that's it.

>> > How about defaulting to auto-revert-use-notify = nil when
>> > global-auto-revert-mode is turned on?
>> 
>> I don't know whether it is the majority of users, who enable
>> global-auto-revert-mode *and* work with hundreds of buffers. So far,
>> there is one report about.
>> 
>> And such power users are more likely to know how to disable file
>> notification then.
>
> Perhaps we shouldn't wait for a flood of bug reports, and do this
> proactively?

I've explained my plans how to protect the libraries, using an internal
limit. This shall avoid such a flood of bug reports.

And if the changes are small enough (likely they are), they could go
even into the emacs-25 branch.

Bst regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 20:51:27 +0100
> 
> > Perhaps we shouldn't wait for a flood of bug reports, and do this
> > proactively?
> 
> I've explained my plans how to protect the libraries, using an internal
> limit. This shall avoid such a flood of bug reports.

I meant to do the above one emacs-25, and only there.

> And if the changes are small enough (likely they are), they could go
> even into the emacs-25 branch.

I very much doubt that we should install such non-trivial changes on
the release branch.  That's why I proposed to change the default,
which sounds like a much safer alternative.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> I very much doubt that we should install such non-trivial changes on
> the release branch.  That's why I proposed to change the default,
> which sounds like a much safer alternative.

And change it back in master? Well, that sounds OK to me.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 21:06:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I very much doubt that we should install such non-trivial changes on
> > the release branch.  That's why I proposed to change the default,
> > which sounds like a much safer alternative.
> 
> And change it back in master?

Yes, of course.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I very much doubt that we should install such non-trivial changes on
>> > the release branch.  That's why I proposed to change the default,
>> > which sounds like a much safer alternative.
>> 
>> And change it back in master?
>
> Yes, of course.

Done in emacs-25 branch.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sun, 28 Feb 2016 10:57:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > I very much doubt that we should install such non-trivial changes on
> >> > the release branch.  That's why I proposed to change the default,
> >> > which sounds like a much safer alternative.
> >> 
> >> And change it back in master?
> >
> > Yes, of course.
> 
> Done in emacs-25 branch.

Thanks.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> Date: Sat, 27 Feb 2016 20:00:30 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 22814@debbugs.gnu.org
> 
> I don't think the problem is what kqueue does when it run out of file descriptors, but how the rest of the Emacs
> process acts when this happens. For example, can it even read and write files? Can subprocesses be
> started?

Even if it can't, it shouldn't hang.  It could signal an error for any
operation that needs a file descriptor, but it shouldn't hang.  Then
the user could kill one of the buffers under auto-revert, or manually
switch to not using notifications, and be able to continue the
session.

Btw, my recommendation is to turn off auto-revert-use-notify in any
session that uses global-auto-revert-mode.  File notifications simply
don't scale up well enough for that, given that Emacs sessions tend to
run for many weeks and have many hundreds of file-visiting buffers.
Also, if you somehow end up visiting a file in /tmp, your Emacs will
get notifications about every temp file operation on the OS, which
will probably slow it down quite a lot.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Even if it can't, it shouldn't hang.  It could signal an error for any
> operation that needs a file descriptor, but it shouldn't hang.  Then
> the user could kill one of the buffers under auto-revert, or manually
> switch to not using notifications, and be able to continue the
> session.

But this doesn't seem to hang in kqueue. My test has shown, that it
returned with a proper

Test file-notify-test09-sufficient-ressources condition:
    (file-error "File cannot be opened" "Too many open files in system" "/tmp/file-notify-test-parent112045XZ/file-notify-test11204ZxG")

The hang must be somewhere else in Emacs, where the request for a new
file descriptor is assumed to work w/o check.

> Btw, my recommendation is to turn off auto-revert-use-notify in any
> session that uses global-auto-revert-mode.  File notifications simply
> don't scale up well enough for that, given that Emacs sessions tend to
> run for many weeks and have many hundreds of file-visiting buffers.

We have already auto-revert-use-notify.

> Also, if you somehow end up visiting a file in /tmp, your Emacs will
> get notifications about every temp file operation on the OS, which
> will probably slow it down quite a lot.

Not necessarily for every backend.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Anders Lindgren <andlind@gmail.com>,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 20:26:07 +0100
> 
> The hang must be somewhere else in Emacs, where the request for a new
> file descriptor is assumed to work w/o check.

That's what I meant: something, somewhere is not working correctly.

> > Also, if you somehow end up visiting a file in /tmp, your Emacs will
> > get notifications about every temp file operation on the OS, which
> > will probably slow it down quite a lot.
> 
> Not necessarily for every backend.

But with Dired open on /tmp, it is.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Also, if you somehow end up visiting a file in /tmp, your Emacs will
>> > get notifications about every temp file operation on the OS, which
>> > will probably slow it down quite a lot.
>> 
>> Not necessarily for every backend.
>
> But with Dired open on /tmp, it is.

Not with kqueue.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> The hang must be somewhere else in Emacs, where the request for a new
>> file descriptor is assumed to work w/o check.
>
> That's what I meant: something, somewhere is not working correctly.

I've improved the test case. The file-error is trapped, and the test
continues. Now I get

Test file-notify-test09-sufficient-ressources condition:
    (error "Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")

The Lisp backtrace doesn't tell anything useful. What could I do now?
I've recompiled lisp/emacs-lisp/cl-seq.el, of course.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 20:56:29 +0100
> 
> I've improved the test case. The file-error is trapped, and the test
> continues. Now I get
> 
> Test file-notify-test09-sufficient-ressources condition:
>     (error "Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
> 
> The Lisp backtrace doesn't tell anything useful. What could I do now?

Set a breakpoint in Fsignal, and see who signals the error, and why.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
>> Date: Sat, 27 Feb 2016 20:56:29 +0100
>>
>> I've improved the test case. The file-error is trapped, and the test
>> continues. Now I get
>>
>> Test file-notify-test09-sufficient-ressources condition:
>>     (error "Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
>>
>> The Lisp backtrace doesn't tell anything useful. What could I do now?
>
> Set a breakpoint in Fsignal, and see who signals the error, and why.

--8<---------------cut here---------------start------------->8---
Breakpoint 5, Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) pp error_symbol
error
(gdb) pp data
("Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
(gdb) xbacktrace
"cl-intersection" (0xffffccc0)
"ert--should-error-handle-error" (0xffffcd60)
"condition-case" (0xffffcf68)
"let" (0xffffd088)
"let" (0xffffd1a8)
"let" (0xffffd2c8)
"let" (0xffffd3e8)
"unwind-protect" (0xffffd4c8)
0x1b99710 Lisp type 3
"ert--run-test-internal" (0xffffd7c0)
"ert-run-test" (0xffffd948)
"ert-run-or-rerun-test" (0xffffdae8)
"ert-run-tests" (0xffffdc68)
"ert" (0xffffdea0)
"funcall-interactively" (0xffffde98)
"call-interactively" (0xffffe120)
"command-execute" (0xffffe2d8)
"command-line-1" (0xffffe440)
"command-line" (0xffffe608)
"normal-top-level" (0xffffe6d0)
"nil" (0x0)
0 (0x15ab400)
0xe04620 Lisp type 4
0x1ae63b0 Lisp type 3
Error accessing memory address 0x37393832746e6588: Bad address.
(gdb) bt
#0  Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
#1  0x000000000050b0a9 in xsignal (error_symbol=15024, data=95357875) at eval.c:1577
#2  0x000000000050970c in xsignal1 (error_symbol=<value optimized out>, arg=<value optimized out>) at eval.c:1592
#3  0x000000000050b173 in verror (m=<value optimized out>, ap=<value optimized out>) at eval.c:1770
#4  0x0000000000509632 in error (m=0x3ab0 <Error reading address 0x3ab0: Bad address>) at eval.c:1782
#5  0x000000000050c921 in Ffetch_bytecode (object=<value optimized out>) at eval.c:2949
#6  0x000000000050c53f in funcall_lambda (fun=12117621, nargs=2, arg_vector=0x7fffffffccc0) at eval.c:2854
#7  0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#8  0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=22872277, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#9  0x000000000050b61a in apply_lambda (fun=22872381, args=<value optimized out>, count=<value optimized out>) at eval.c:2794
#10 0x0000000000508a14 in eval_sub (form=<value optimized out>) at eval.c:2211
#11 0x000000000050a889 in internal_lisp_condition_case (var=11746680, bodyform=<value optimized out>, handlers=<value optimized out>) at eval.c:426
#12 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#13 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#14 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#15 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#16 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#17 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#18 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#19 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#20 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#21 0x000000000050a64e in Funwind_protect (args=28974979) at eval.c:1170
#22 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#23 0x000000000050c7c9 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:426
#24 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#25 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23072773, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#26 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#27 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23073197, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#28 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#29 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23488237, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#30 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#31 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23488597, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#32 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#33 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23546765, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#34 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#35 0x0000000000506644 in Ffuncall_interactively (nargs=15024, args=0x5af0bb3) at callint.c:248
#36 0x000000000050bc5e in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2673
#37 0x000000000050b86d in Fapply (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2321
#38 0x0000000000506b26 in Fcall_interactively (function=4839752, record_flag=<value optimized out>, keys=<value optimized out>) at callint.c:385
#39 0x000000000050bd63 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2700
#40 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=8926749, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880

[...]
--8<---------------cut here---------------end--------------->8---

Emacs was compiled with "gmake bootstrap". I'll keep the gdb session open.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Mon, 29 Feb 2016 11:24:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Michael Albinus <michael.albinus@gmx.de>
> >> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> >> Date: Sat, 27 Feb 2016 20:56:29 +0100
> >>
> >> I've improved the test case. The file-error is trapped, and the test
> >> continues. Now I get
> >>
> >> Test file-notify-test09-sufficient-ressources condition:
> >>     (error "Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
> >>
> >> The Lisp backtrace doesn't tell anything useful. What could I do now?
> >
> > Set a breakpoint in Fsignal, and see who signals the error, and why.
> 
> --8<---------------cut here---------------start------------->8---
> Breakpoint 5, Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) pp error_symbol
> error
> (gdb) pp data
> ("Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
> (gdb) xbacktrace
> "cl-intersection" (0xffffccc0)
> "ert--should-error-handle-error" (0xffffcd60)
> "condition-case" (0xffffcf68)
> "let" (0xffffd088)
> "let" (0xffffd1a8)
> "let" (0xffffd2c8)
> "let" (0xffffd3e8)
> "unwind-protect" (0xffffd4c8)
> 0x1b99710 Lisp type 3
> "ert--run-test-internal" (0xffffd7c0)
> "ert-run-test" (0xffffd948)
> "ert-run-or-rerun-test" (0xffffdae8)
> "ert-run-tests" (0xffffdc68)
> "ert" (0xffffdea0)
> "funcall-interactively" (0xffffde98)
> "call-interactively" (0xffffe120)
> "command-execute" (0xffffe2d8)
> "command-line-1" (0xffffe440)
> "command-line" (0xffffe608)
> "normal-top-level" (0xffffe6d0)
> "nil" (0x0)
> 0 (0x15ab400)
> 0xe04620 Lisp type 4
> 0x1ae63b0 Lisp type 3
> Error accessing memory address 0x37393832746e6588: Bad address.
> (gdb) bt
> #0  Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
> #1  0x000000000050b0a9 in xsignal (error_symbol=15024, data=95357875) at eval.c:1577
> #2  0x000000000050970c in xsignal1 (error_symbol=<value optimized out>, arg=<value optimized out>) at eval.c:1592
> #3  0x000000000050b173 in verror (m=<value optimized out>, ap=<value optimized out>) at eval.c:1770
> #4  0x0000000000509632 in error (m=0x3ab0 <Error reading address 0x3ab0: Bad address>) at eval.c:1782
> #5  0x000000000050c921 in Ffetch_bytecode (object=<value optimized out>) at eval.c:2949

Crystal ball says something went wrong inside read_doc_string that was
called just before the call to 'error'.  That function calls
emacs_open, and you have run out file descriptors.  Can you see what's
going on inside that call?  (That would require re-running the test
with a suitably conditioned breakpoint.)

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Crystal ball says something went wrong inside read_doc_string that was
> called just before the call to 'error'.  That function calls
> emacs_open, and you have run out file descriptors.  Can you see what's
> going on inside that call?  (That would require re-running the test
> with a suitably conditioned breakpoint.)

Indeed, Emacs tries to read the docstring of the just fetched
function. And it tries to open etc/DOC for this, which fails due to the
missing file descriptor availability.

I don't believe we need to handle this case; if Emacs is running out of
file descriptors, anything could happen.

I'm testing a patch for kqueue.c, which limits the open file
notification descriptors, as proposed by Anders. According to my tests
this is not necessary for inotify.c (contrary to what I've assumed).
Will commit the patch once the current emacs-25 commits are merged to
the master.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Wed, 02 Mar 2016 16:03:29 +0100
> 
> > Crystal ball says something went wrong inside read_doc_string that was
> > called just before the call to 'error'.  That function calls
> > emacs_open, and you have run out file descriptors.  Can you see what's
> > going on inside that call?  (That would require re-running the test
> > with a suitably conditioned breakpoint.)
> 
> Indeed, Emacs tries to read the docstring of the just fetched
> function. And it tries to open etc/DOC for this, which fails due to the
> missing file descriptor availability.
> 
> I don't believe we need to handle this case; if Emacs is running out of
> file descriptors, anything could happen.

The only part that might be worth improving is the error message: it's
a far cry from what really went wrong.  If you can find a way of
making it say something about "too many open files", that'd be all the
improvement we can hope for.

> I'm testing a patch for kqueue.c, which limits the open file
> notification descriptors, as proposed by Anders. According to my tests
> this is not necessary for inotify.c (contrary to what I've assumed).
> Will commit the patch once the current emacs-25 commits are merged to
> the master.

Thanks.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Indeed, Emacs tries to read the docstring of the just fetched
>> function. And it tries to open etc/DOC for this, which fails due to the
>> missing file descriptor availability.
>> 
>> I don't believe we need to handle this case; if Emacs is running out of
>> file descriptors, anything could happen.
>
> The only part that might be worth improving is the error message: it's
> a far cry from what really went wrong.  If you can find a way of
> making it say something about "too many open files", that'd be all the
> improvement we can hope for.

I would apply the following patch:

--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/emacs-25/src/doc.c.~2e78353fabe11c768627c50e48375de5693ce7ee~
--- /home/albinus/src/emacs-25/src/doc.c
***************
*** 126,131 ****
--- 126,134 ----
    fd = emacs_open (name, O_RDONLY, 0);
    if (fd < 0)
      {
+       if ((errno == EMFILE) || (errno == ENFILE))
+ 	report_file_error ("Read error on documentation file", file);
+ 
  #ifndef CANNOT_DUMP
        if (!NILP (Vpurify_flag))
  	{
--8<---------------cut here---------------end--------------->8---

This ends up in the following error message:

Read error on documentation file: Too many open files, /home/albinus/src/emacs-25/lisp/emacs-lisp/cl-seq.elc

Is it OK to apply it to the emacs-25 branch, or shall it go to master?

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

>>>>> Michael Albinus <michael.albinus@gmx.de> writes:

> This ends up in the following error message:

> Read error on documentation file: Too many open files,
> /home/albinus/src/emacs-25/lisp/emacs-lisp/cl-seq.elc

> Is it OK to apply it to the emacs-25 branch, or shall it go to master?

I'd like to have this on emacs-25. It's just unfortunate that it hasn't been
in any of the pretests. But if the alternative is a more confusing error
situation, then it's better for the bug reports that come to be specific.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Fri, 04 Mar 2016 08:53:24 +0100
> 
> > The only part that might be worth improving is the error message: it's
> > a far cry from what really went wrong.  If you can find a way of
> > making it say something about "too many open files", that'd be all the
> > improvement we can hope for.
> 
> I would apply the following patch:
> 
> --8<---------------cut here---------------start------------->8---
> *** /home/albinus/src/emacs-25/src/doc.c.~2e78353fabe11c768627c50e48375de5693ce7ee~
> --- /home/albinus/src/emacs-25/src/doc.c
> ***************
> *** 126,131 ****
> --- 126,134 ----
>     fd = emacs_open (name, O_RDONLY, 0);
>     if (fd < 0)
>       {
> +       if ((errno == EMFILE) || (errno == ENFILE))
> + 	report_file_error ("Read error on documentation file", file);
> + 
>   #ifndef CANNOT_DUMP
>         if (!NILP (Vpurify_flag))
>   	{
> --8<---------------cut here---------------end--------------->8---
> 
> This ends up in the following error message:
> 
> Read error on documentation file: Too many open files, /home/albinus/src/emacs-25/lisp/emacs-lisp/cl-seq.elc

LGTM.

> Is it OK to apply it to the emacs-25 branch, or shall it go to master?

Please commit to emacs-25, and thanks.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is it OK to apply it to the emacs-25 branch, or shall it go to master?
>
> Please commit to emacs-25, and thanks.

Done.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm testing a patch for kqueue.c, which limits the open file
>> notification descriptors, as proposed by Anders. According to my tests
>> this is not necessary for inotify.c (contrary to what I've assumed).
>> Will commit the patch once the current emacs-25 commits are merged to
>> the master.
>
> Thanks.

Committed to master. Plus a new test file-notify-test09-sufficient-ressources.

Anders, do you want to test it, or shall I close this bug report just now?

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I'm testing a patch for kqueue.c, which limits the open file
>>> notification descriptors, as proposed by Anders. According to my tests
>>> this is not necessary for inotify.c (contrary to what I've assumed).
>>> Will commit the patch once the current emacs-25 commits are merged to
>>> the master.
>>
>> Thanks.
>
> Committed to master. Plus a new test file-notify-test09-sufficient-ressources.
>
> Anders, do you want to test it, or shall I close this bug report just now?

Ping.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Hi!

I just took a quick look at this. I noticed that turning on
global-auto-revert-mode disables file notifications. Is this still needed
when your new system is in place? Personally, I would like to see it revert
to the old timer system only when running out of resources.

Apart from that, everything looks good. Emacs seems to be running fine even
when I have 400 buffers open with global auto-revert enabled.

    -- Anders


On Sun, Apr 10, 2016 at 10:21 AM, Michael Albinus <michael.albinus@gmx.de>
wrote:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> I'm testing a patch for kqueue.c, which limits the open file
> >>> notification descriptors, as proposed by Anders. According to my tests
> >>> this is not necessary for inotify.c (contrary to what I've assumed).
> >>> Will commit the patch once the current emacs-25 commits are merged to
> >>> the master.
> >>
> >> Thanks.
> >
> > Committed to master. Plus a new test
> file-notify-test09-sufficient-ressources.
> >
> > Anders, do you want to test it, or shall I close this bug report just
> now?
>
> Ping.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 1816 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

> Hi!

Hi Anders,

> I just took a quick look at this. I noticed that turning on
> global-auto-revert-mode disables file notifications. Is this still
> needed when your new system is in place? Personally, I would like to
> see it revert to the old timer system only when running out of
> resources.

Really? This shall happen on the emacs-25 branch only. In the master
branch, there's no such code in autorevert.el. And that's also the
branch the fix in kqueue.c has been committed to.

> -- Anders

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Mon, Apr 11, 2016 at 8:40 AM, Michael Albinus <michael.albinus@gmx.de>
wrote:

> Anders Lindgren <andlind@gmail.com> writes:
>
> > Hi!
>
> Hi Anders,
>
> > I just took a quick look at this. I noticed that turning on
> > global-auto-revert-mode disables file notifications. Is this still
> > needed when your new system is in place? Personally, I would like to
> > see it revert to the old timer system only when running out of
> > resources.
>
> Really? This shall happen on the emacs-25 branch only. In the master
> branch, there's no such code in autorevert.el. And that's also the
> branch the fix in kqueue.c has been committed to.
>
>
I tested on the emacs-25 branch.

I guess what I saw was the effect of the fact that global auto-revet mode
disables notifications.

I'll redo the test on the master branch.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1459 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

> I tested on the emacs-25 branch.
>
> I guess what I saw was the effect of the fact that global auto-revet
> mode disables notifications.

At least you have confirmed there's no problem left in the emacs-25
branch. Good for the release :-)

> I'll redo the test on the master branch.

Thanks!

> -- Anders

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

>
> > I'll redo the test on the master branch.
>
> Thanks!


I just redid the test on the master branch. I managed to open 400+ files
with global auto-revert enabled and Emacs reverted files nicely. I,
honestly, don't know if the notification system was enabled,
auto-revert-use-notify was t though.

Michael, I would like to take the opportunity to thank you for taking care
of, and continuing developing, my old auto-revert package!

    -- Anders

[-- Attachment #2: Type: text/html, Size: 834 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Version: 25.2

Anders Lindgren <andlind@gmail.com> writes:

> I just redid the test on the master branch. I managed to open 400+
> files with global auto-revert enabled and Emacs reverted files nicely.

So I'm closing the bug. Thanks for testing!

> I, honestly, don't know if the notification system was enabled,
> auto-revert-use-notify was t though.

If file notification is used, the buffer-local variable
auto-revert-notify-watch-descriptor is non-nil for buffers in
auto-revert-mode.

> -- Anders

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

>
> > If Emacs hangs because the file notification system runs out of
> > resources (file descriptors or processes), it should detect this by
> > itself and revert to other, safer, methods (e.g. the timer-based
> > system).
>
> A general support for polling in filenotify.el is not foreseen, too much
> effort. But I believe, in the auto-revert case Emacs works already this
> way. When file-notify-add-watch returns nil, auto-revert falls back to
> polling (to be tested, I'll I add a test).
>

This sounds like the right thing to do.

The main question is why Emacs hangs when opening a large desktop (which is
why I didn't want this bug to be closed), even though the file notify
system has this fallback.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1077 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> Date: Sat, 27 Feb 2016 10:55:42 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22814@debbugs.gnu.org
> 
>  A general support for polling in filenotify.el is not foreseen, too much
>  effort. But I believe, in the auto-revert case Emacs works already this
>  way. When file-notify-add-watch returns nil, auto-revert falls back to
>  polling (to be tested, I'll I add a test).
> 
> This sounds like the right thing to do.
> 
> The main question is why Emacs hangs when opening a large desktop (which is why I didn't want this bug to
> be closed), even though the file notify system has this fallback.

Can you debug this?

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Sat, Feb 27, 2016 at 11:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 27 Feb 2016 10:55:42 +0100
> > From: Anders Lindgren <andlind@gmail.com>
> > Cc: 22814@debbugs.gnu.org
> >
> >  A general support for polling in filenotify.el is not foreseen, too much
> >  effort. But I believe, in the auto-revert case Emacs works already this
> >  way. When file-notify-add-watch returns nil, auto-revert falls back to
> >  polling (to be tested, I'll I add a test).
> >
> > This sounds like the right thing to do.
> >
> > The main question is why Emacs hangs when opening a large desktop (which
> is why I didn't want this bug to
> > be closed), even though the file notify system has this fallback.
>
> Can you debug this?
>

Not within a reasonable time frame, unfortunately.

In can put it on the NS Wishlist, and hope that someone picks up on it.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1554 bytes --]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

>     Can you debug this?
>
> Not within a reasonable time frame, unfortunately.

I've debugged this on FreeBSD 10. It has larger limits:

--8<---------------cut here---------------start------------->8---
albinus@freebsd10:~/src/emacs-25 % ulimit -u
5749
albinus@freebsd10:~/src/emacs-25 % ulimit -n
28791
--8<---------------cut here---------------end--------------->8---




1. Run unlimited number of file-notify-add-watch:

--8<---------------cut here---------------start------------->8---
      (let ((temporary-file-directory file-notify--test-tmpfile))
	(while t
	  (setq file-notify--test-tmpfile1 (file-notify--test-make-temp-name))
	  (write-region
	   "any text" nil file-notify--test-tmpfile1 nil 'no-message)
	  (should (file-notify-add-watch
		   file-notify--test-tmpfile1 '(change) #'ignore))))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
albinus@freebsd10:~/src/emacs-25 % gmake -C test/automated file-notify-tests SELECTOR='\"09\"'
Test file-notify-test09-sufficient-ressources condition:
    (file-error "Opening output file" "Too many open files in system" "/tmp/file-notify-test-parent11031I_Y/file-notify-test11031BbD")
   FAILED  1/2  file-notify-test09-sufficient-ressources
 
albinus@freebsd10:~/src/emacs-25 % ls /tmp/file-notify-test-parent11031I_Y | wc -l
   20291
--8<---------------cut here---------------end--------------->8---




2. Run limited number of file-notify-add-watch:

--8<---------------cut here---------------start------------->8---
      (let ((temporary-file-directory file-notify--test-tmpfile))
	(dotimes (_i 10000)
	  (setq file-notify--test-tmpfile1 (file-notify--test-make-temp-name))
	  (write-region
	   "any text" nil file-notify--test-tmpfile1 nil 'no-message)
	  (should (file-notify-add-watch
		   file-notify--test-tmpfile1 '(change) #'ignore)))
	(read))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
albinus@freebsd10:~/src/emacs-25 % gmake -C test/automated file-notify-tests SELECTOR='\"09\"'
[...]

root@freebsd10:~ # lsof -p 11075 | grep file-notify-test | wc -l
   10000
--8<---------------cut here---------------end--------------->8---




Obviously, Emacs keeps an open file descriptor per watched file, as expected.

> -- Anders

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 13:17:50 +0100
> 
> albinus@freebsd10:~/src/emacs-25 % gmake -C test/automated file-notify-tests SELECTOR='\"09\"'
> [...]
> 
> root@freebsd10:~ # lsof -p 11075 | grep file-notify-test | wc -l
>    10000
> --8<---------------cut here---------------end--------------->8---
> 
> 
> Obviously, Emacs keeps an open file descriptor per watched file, as expected.

Obviously.  But the question was why loading a desktop file hangs in
that situation.  I don't think your testing answers that question, or
did I miss something?

Thanks.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> But the question was why loading a desktop file hangs in
> that situation.  I don't think your testing answers that question, or
> did I miss something?

Anders wrote "opening a large desktop", NOT "opening a large desktop
file". I suppose he meant the problem of the OP, auto-reverting 600+
Emacs buffers.

> Thanks.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Sat, 27 Feb 2016 13:49:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the question was why loading a desktop file hangs in
> > that situation.  I don't think your testing answers that question, or
> > did I miss something?
> 
> Anders wrote "opening a large desktop", NOT "opening a large desktop
> file". I suppose he meant the problem of the OP, auto-reverting 600+
> Emacs buffers.

If so, I'm sorry for my misunderstanding.

Still, the "hangs" part is troubling.  Do your findings explain why
Emacs would hang doing anything when it runs out file descriptors?

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Still, the "hangs" part is troubling.  Do your findings explain why
> Emacs would hang doing anything when it runs out file descriptors?

No idea. My test returned a file-error, which sounds appropriate. File
notification (kqueue) seems to behave proper, reporting this.

Best regards, Michael.

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

> +   if ((errno == EMFILE) || (errno == ENFILE))
> + 	report_file_error ("Read error on documentation file", file);

This new code should be after the 2nd call to 'emacs_open', not after the 1st. 
The difference is unlikely to matter, but still.... I installed the attached 
further patch.

[-- Attachment #2: 0001-doc-string-file-descriptor-exhaustion-fix.patch --]
[-- Type: text/x-diff, Size: 1155 bytes --]

From d5e42616a0b5c0b0f0d1b01982d7b949bf8ddc0d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 4 Mar 2016 16:29:55 -0800
Subject: [PATCH] doc string file descriptor exhaustion fix

* src/doc.c (get_doc_string): Move newly-added check to a better
location (Bug#22814).
---
 src/doc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/doc.c b/src/doc.c
index 6e79065..a20ecbd 100644
--- a/src/doc.c
+++ b/src/doc.c
@@ -126,9 +126,6 @@ get_doc_string (Lisp_Object filepos, bool unibyte, bool definition)
   fd = emacs_open (name, O_RDONLY, 0);
   if (fd < 0)
     {
-      if ((errno == EMFILE) || (errno == ENFILE))
-	report_file_error ("Read error on documentation file", file);
-
 #ifndef CANNOT_DUMP
       if (!NILP (Vpurify_flag))
 	{
@@ -141,6 +138,9 @@ get_doc_string (Lisp_Object filepos, bool unibyte, bool definition)
 #endif
       if (fd < 0)
 	{
+	  if (errno == EMFILE || errno == ENFILE)
+	    report_file_error ("Read error on documentation file", file);
+
 	  SAFE_FREE ();
 	  AUTO_STRING (cannot_open, "Cannot open doc string file \"");
 	  AUTO_STRING (quote_nl, "\"\n");
-- 
2.5.0