Error while checking syntax automatically (file-error)

[pepone]

Each time I save a JS buffer or edit it I getting this error, and editing the JS buffer becomes slow to the point that it becomes unusable.

Debugger entered--Lisp error: (file-error "Writing to process" "Invalid argument" #<process flycheck-javascript-eslint>)
  signal(file-error ("Writing to process" "Invalid argument" #<process flycheck-javascript-eslint>))
  flycheck-buffer()
  flycheck-buffer-automatically((idle-change))
  flycheck--handle-idle-trigger(#<buffer Client.js>)
  apply(flycheck--handle-idle-trigger #<buffer Client.js>)
  timer-event-handler([t 23576 50416 273719 nil flycheck--handle-idle-trigger (#<buffer Client.js>) nil 0])
  read-event(nil t 1)
  sit-for(1)
  blink-matching-open()
  blink-paren-post-self-insert-function()
  self-insert-command(1)
  funcall-interactively(self-insert-command 1)
  call-interactively(self-insert-command nil nil)
  command-execute(self-insert-command)

Syntax checkers for buffer Client.js in js-mode:

  javascript-eslint
    - may enable:  yes
    - executable:  Found at c:/Users/ppgut/AppData/Roaming/npm/eslint.cmd
    - config file: found

  javascript-jshint
    - may enable:         Automatically disabled!
    - executable:         Not found
    - configuration file: Not found

  javascript-standard
    - may enable: Automatically disabled!
    - executable: Not found

Flycheck Mode is enabled.  Use C-u C-c ! x to enable disabled
checkers.

--------------------

Flycheck version: 32snapshot (package: 20181214.1048)
Emacs version:    26.1
System:           x86_64-w64-mingw32
Window system:    w32

js>c:/Users/ppgut/AppData/Roaming/npm/eslint.cmd -v
v5.8.0

[fmdkdd]

Hmm that looks bad. It happens on every JS buffer you say? But not for other languages?

cc @flycheck/javascript

[pepone]

I also use python-flake8 and don't see any issues there

[fmdkdd]

@pepone Good to know. It may be a windows issue with eslint and Emacs processes... can't really know as I can't reproduce.

If you have reliable steps to reproduce, please share. Until then, there is little hope to find a solution.

[baerrach]

I have the same problem, and am on windows as well.

Flycheck version: 32snapshot (package: 20190425.816)
Emacs version:    26.2
System:           x86_64-w64-mingw32
Window system:    w32

Its only affecting one file so far.

If I change the file to have something simple like const foo = 'bar'; then it works.
Putting the original file contents back fails.
If I start chopping out large sections it starts working again, which sections I chop out doens't matter.
This tends to imply its a size related issue.

The files only has 359 lines, and I've not had this problem before on much larger files.

My emacs fu is limited to hacking init.el and friends, and toggle the debugger :)

This doesn't look like its particular to flycheck but something to do with emacs + windows.
But I can't find anything in google that is recent to indicate the problem.

[soeik]

I'm having the same problem. It just started to happen recently in the project and with files, I edited before without any problems.

[baerrach]

@soeik If you work out which package is causing the problem post back.
But its not flycheck,,,

[cpitclaudel]

Is there a specific size threshold at which this starts happening? And did the issue pop up after updating to a new Emacs?

[baerrach]

Sorry, I dont have answers for that.
I started a new job, which meant a new Emacs, but same old config.
I think its happening at home where I haven't updated Emacs but I am not sure if I have checked.

I'll look into providing some more diagnostics, but its not Flycheck's problem it must be an interaction with another package.

As notes on May 9th, I'm happy to have a crack investigating but my debugging skills are limited.

[cpitclaudel]

As notes on May 9th, I'm happy to have a crack investigating but my debugging skills are limited.

Thanks for the offer. If the cut-off is a specific value, this might suggest buffer-related issues. We've had one like this in Emacs before. nodejs/node#4697

[baerrach]

Okay,

I've run emacs -q, and only run eval-last-sexp on

Attempt 1

• setting up my loadpath
• package
• use-package
• adding node modules to path
• js2-mode
• flycheck-mode

and the problem still exists

Attempt 2

(package-initialize)
(require 'add-node-modules-path)
(add-node-modules-path)
(require 'flycheck)
; M-x flycheck-verify-setup is working for elsint
; M-x flycheck-mode in the problem buffer

Still getting

Error while checking syntax automatically: (file-error "Writing to process" "Invalid argument" #<process flycheck-javascript-eslint>)

[baerrach]

Culling the file from 18806 characters to 7369 characters and the problem goes away.

[baerrach]

I've learnt how to use Edebug recently, so I figured I'd go into the source code and run C-u C-M-x (eval-defun) to instrument the function and step through it.

Got temporarily stalled via function call indirection. Added instrumentation to flycheck-start-command-checker which is where the magic happens.

The problem is in the call to flycheck-process-send-buffer line 5453 in flycheck.el (flycheck-20190828.1147)

          (when (flycheck-checker-get checker 'standard-input)
            (flycheck-process-send-buffer process))

[baerrach]

flycheck-process-send-buffer is a compiled Lisp function in ‘flycheck.el’.

(flycheck-process-send-buffer PROCESS)

Send all contents of current buffer to PROCESS.

Sends all contents of the current buffer to the standard input of
PROCESS, and terminates standard input with EOF.

If ‘flycheck-chunked-process-input’ is non-nil, send buffer
contents in chunks via
‘flycheck--process-send-buffer-contents-chunked’, which see.
Otherwise use ‘process-send-region’ to send all contents at once
and rely on Emacs’ own buffering and chunking.

And

flycheck-chunked-process-input is a variable defined in ‘flycheck.el’.
Its value is nil

Documentation:
If non-nil send process input in small chunks.

If this variable is non-nil ‘flycheck-process-send-buffer’ sends
buffer contents in small chunks.

Defaults to nil, except on Windows to work around Emacs bug
#22344.

See https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00419.html

Running (setq flycheck-chunked-process-input t) and trying again gets me

(file-error "Writing to process" "Bad file descriptor" #<process flycheck-javascript-eslint>)

[baerrach]

Following that email thread finally links me to #794 and look there I am in that thread too... Why didn't I find that first time?

My workaround there no longer relevant.

And Xeveo link https://github.com/Xeveo/flycheck/commit/8b472e52ce4ad82158e4aaf49dc8d6eedc70923f is now dead, and as noted in the other thread, reverting stdin isn't the way to fix this.

On a command prompt I ran

type LARGEFILE.js | node PATH_TO\eslint\bin\eslint.js --stdin

and it fails at pretty much 4k.

>node --version
v10.15.3

@cpitclaudel In this emacs bug thread https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00550.html you mention that you raised an issue with node, but there was no link to the issue you raised and I can not find that issue. Is there any chance that you can find it again?

[baerrach]

Using (setq flycheck-chunked-process-input t) I can see the chunked data being sent to the process correctly, it is not until it calls (process-send-eof process) in flycheck-process-send-buffer that this error occurs.

Suspicious state from syntax checker javascript-eslint: Flycheck checker javascript-eslint returned non-zero exit code 2, but its output contained no errors: Error: EOF: end of file, read
    at Object.readSync (fs.js:493:3)
    at tryReadSync (fs.js:332:20)
    at Object.readFileSync (fs.js:369:19)
    at Object.<anonymous> (c:\ide\frontend\node_modules\eslint\bin\eslint.js:66:53)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)

[baerrach]

@cpitclaudel I found your node issue, I should have search by your github username!
nodejs/node#4697

[baerrach]

rejoice I have a workaround!

In the nodejs/node#4697 I've discovered the source of the problem is eslint and its handling of stdin.

I don't know what the correct long term solution is, but I'll post in here too when I find it.

For now you can hack your local version of eslint.

node_modules/eslint/bin/eslint.js and replace the useStdIn block with the one below.

if (useStdIn) {

    /*
     * Note: `process.stdin.fd` is not used here due to https://github.com/nodejs/node/issues/7439.
     * Accessing the `process.stdin` property seems to modify the behavior of file descriptor 0, resulting
     * in an error when stdin is piped in asynchronously.
     */

  const input = [];

  process.stdin.on('readable', () => {
    let chunk;
    // Use a loop to make sure we read all available data.
    while ((chunk = process.stdin.read()) !== null) {
      input.push(chunk);
    }
  });

  process.stdin.on('end', () => {
    const contents = input.join('');
    process.exitCode = cli.execute(process.argv, contents, "utf8");
  });

} else if (init) {

[cpitclaudel]

!! Thanks so much for this exceptional sleuthing work :)

[fmdkdd]

@baerrach Nice investigation! I see you have raised the issue with the ESLint folks. I'll file this as upstream and close the issue, since the fix is not on Flycheck's side.

Feel free to update us when it does get fixed though.

[mohkale]

can confirm @baerrach solution works wonders. heres a link to the issue on eslint. hopefully it'll be merged soon. thanks again :)