Adding blacken_mode as a python-mode-hook eventually runs out of file handles.

[rec]

I set the black package so it blacks on save:

(add-hook 'python-mode-hook 'blacken-mode)

That worked fine for about a day, and then my emacs refused to open new files or save existing files after that, until I restart!

(Lucky I am constantly saving my buffers so I lost perhaps ten keystrokes... :-) )

It happened three times before I figured out that it was that one line above. I commented it out and restarted and it's days later and I've seen no issues.

I should have written down the error messages but I was in a hurry - also, I didn't realize it was the black package until I looked at what changes I'd made to my .emacsrc.

The message seemed to me to be implying that emacs had run out of file handles, so my guess is that the black package is somehow leaking file handles.

---

I'm on Aquamacs for MacOS, a GUI wrapper for emacs. I've been using it for a decade or and the compatibility has been extremely good.

Aquamacs 3.4 GNU Emacs 25.3.50.1 (x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 10.10.5 (Build 14F27)) dated 2018-07-27 rev. 53e2a47a8fbbfce9586fd76891478ac5851ac3b5

[CeleritasCelery]

In order to debug this we will need the error message you were seeing. I am not convinced that blacken is the culprit here.

[rec]

I'm on holiday now so don't have access to the machine till I get back!

I had never seen this issue before; I installed blacken-mode and I got this multiple times a day; uninstalled blacken-mode after this bug and never saw it again.

IIRC I wasn't getting any error message that would be useful except an Aquamacs "Cannot open file". I'll try this again when I get home.

Sorry, I understand full well that such reports are frustrating and hard to act upon. :-/

[CeleritasCelery]

Try setting toggle-debug-on-error to see if that provides a useful message.

[vcalvert]

I've had this happen to me, though I don't have the error message handy; it's essentially "Too many open files", and a process list showed a very large number tied to the *blacken-error* buffer. Killing that buffer resolved the issue.

Also see this post on Reddit which has an example process list, essentially the same as what I was seeing.

Example process list:

blacken stderr  --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           
blacken stde... --      open    *blacken-error* --           

Reproduction steps:

1. Set blacken to run on save.
2. Create a new python file.
3. Enter some invalid syntax.
4. Save.
5. Note that M-x list-processes shows a blacken process hanging around.
6. Change file and save again (preserving invalid syntax).
7. Note that M-x list-processes shows another blacken process hanging around.
8. Repeat step 6 until you start seeing the "too many open files" error. This shows up on buffer save in the *Warnings* buffer.

Expectation:
In step 5, no blacken process should be observed, OR, in step 7, only one blacken process should be observed, no matter how many times steps 6-7 are repeated.

[leotrs]

I had a similar occurrence yesterday after adding the same line mentioned above.