Uncaught exception error spawn

Error on windows updates — spawn setup.exe EACCES #3623

Version: builder v20.38.5 and updater v4.0.6

Target: —win —x64 —ia32

Hi @develar ,
I have donated in hopes of raising the priority on this issue. It is creating a bit of a large problem with our app that we are trying to release updates to.

Our apps current production version uses Electron v3.0.13, electron-builder v20.31.2, and electron-updater v3.0.3. Whenever we published an update of our app, all users now get the following error whenever the update-downloaded event runs:

This problem seems to only occur on Windows. It didn’t error on macOS, but I have yet to test Linux.

I guess it is a permissions issue. Running the application in administrator mode solves the problem, but this is not a good solutions for thousands of users of the application currently.

This looks like a similar issue: #3480

We’ve also tried publishing an update which upgrades electron-builder to the latest v20.38.5 and electron-updated to v4.0.6, but the same problem still occurs. I believe the broken version is currently in production, so I am not sure how repair this problem for the thousands of users currently using the broken version.

Reproduction steps

1. Download and install version v2.0.0. This version uses builder v20.31.2, and updater v3.0.3
2. Run the application. It will try to update to v3.0.1. This version uses builder v20.38.5 and updater v4.0.6.
3. Observe the error.

You can see that this problem was resolved in the latest builder/updater versions by first installing v3.0.0 and seeing it successfully update to v3.0.1. Both of these use the latest builder v20.38.5 and updater v4.0.6.

How do we repair this problem for our existing users on the broken version so that they can automatically update without having to run the application in administrator mode? This would create a support nightmare if users have to manually work around this error.

The text was updated successfully, but these errors were encountered:

Источник

spawn EAGAIN produces a sequence of uncaught exceptions that cannot be handled #32943

18.04.1-Ubuntu SMP Fri Mar 27 20:11:52 UTC 2020 x86_64 GNU/Linux

What steps will reproduce the bug?

Produced by code that looks like this:

1. In an async function , we call child_process.spawn() .
2. process.on(‘uncaughtException’) gets triggered with an EGAIN on the attempt to spawn the child process. The stack for this uncaught exception looks like [1]. Note that while the triggering condition was in an async function, it was not converted into a promise rejection as I would have expected. The fact that the following exceptions were reported after, despite having synchronous call-stacks back to our call to spawn makes me think this is happening outside JavaScript-land.
3. Next, we get two identical uncaught exceptions, having a stack originating at our code calling spawn [2]. I suspect these are for stdout / stderr , respectively.

How often does it reproduce? Is there a required condition?

This was produced within a docker container on an

80% loaded host with several hundred identical containers in operation.

What is the expected behavior?

EAGAIN exceptions thrown by spawn should be handle-able by user-space code and should not produce uncaught exceptions outside normal control flow.

What do you see instead?

As described above, what appears to be an un-handleable exception thrown outside normal control flow.

Additional information

I also note this comment that makes me suspect the libuv / node-core boundary: #21203 (comment)

The text was updated successfully, but these errors were encountered:

Источник

Why did this happen whenever I opened a python file #311

[coc.nvim] error: Uncaught exception: Error: spawn pyenv ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:469:16)
[coc.nvim] error: Uncaught exception: Error: spawn python3.7 ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:469:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Uncaught exception: Error: spawn python3.6 ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:469:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Uncaught exception: Error: spawn C:Python27python.exe ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:469:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21)

The text was updated successfully, but these errors were encountered:

If you use python3 on linux just replace python with python3 in spawn process

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Error on windows updates — spawn setup.exe EACCES #3623

Version: builder v20.38.5 and updater v4.0.6

Target: —win —x64 —ia32

Hi @develar ,
I have donated in hopes of raising the priority on this issue. It is creating a bit of a large problem with our app that we are trying to release updates to.

Our apps current production version uses Electron v3.0.13, electron-builder v20.31.2, and electron-updater v3.0.3. Whenever we published an update of our app, all users now get the following error whenever the update-downloaded event runs:

This problem seems to only occur on Windows. It didn’t error on macOS, but I have yet to test Linux.

I guess it is a permissions issue. Running the application in administrator mode solves the problem, but this is not a good solutions for thousands of users of the application currently.

This looks like a similar issue: #3480

We’ve also tried publishing an update which upgrades electron-builder to the latest v20.38.5 and electron-updated to v4.0.6, but the same problem still occurs. I believe the broken version is currently in production, so I am not sure how repair this problem for the thousands of users currently using the broken version.

Reproduction steps

1. Download and install version v2.0.0. This version uses builder v20.31.2, and updater v3.0.3
2. Run the application. It will try to update to v3.0.1. This version uses builder v20.38.5 and updater v4.0.6.
3. Observe the error.

You can see that this problem was resolved in the latest builder/updater versions by first installing v3.0.0 and seeing it successfully update to v3.0.1. Both of these use the latest builder v20.38.5 and updater v4.0.6.

How do we repair this problem for our existing users on the broken version so that they can automatically update without having to run the application in administrator mode? This would create a support nightmare if users have to manually work around this error.

The text was updated successfully, but these errors were encountered:

Источник

Running MarkdownPreview throws uncaught exception: Error: spawn xdg-open ENOENT in WSL 2 with terminal Vim #199

I’m using Vim 8.1 inside of Ubuntu 20.04 running in WSL 2 using the latest pull from master at the time of writing this comment.

Inside of WSL 1 this plugin worked great. It would open my default browser when running that command without having to do anything custom.

But now within WSL 2 it fails to run :MarkdownPreview with:

Turns out you need to install sudo apt-get install -y xdg-utils , and then things work fine. Although there is a

5 second delay before it opens where as with WSL 1 it was instant.

Might be worth adding something to the docs or wiki for such an issue in a WSL section.

The text was updated successfully, but these errors were encountered:

I have update README and improve the error message

Turns out you need to install sudo apt-get install -y xdg-utils , and then things work fine. Although there is a

5 second delay before it opens where as with WSL 1 it was instant.

It doesn’t work well for me now in WSL2.
I have changed ip and port, when I execute :MarkdownPreview , my chrome on windows10 will open with site http://172.30.39.164:8854/page/1 , and warn me :

This site can’t be reached
172.30.39.164 refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

What can I do to solve it?

I didn’t change my ip:port and it works here with an address of http://127.0.0.1:8576/page/1 , although there is still a multi-second delay for it to open. I’m running commit faacfbcefe88badb0a5bee3290ec690373552f2b of this plugin.

I would try disabling Windows defender / firewall to see if that fixes anything.

hahahahahhahaha. I have solved it!

I have execute lsof -i in WSL2, and this plugin is listening localhost but not IP address , WSL2 treats Windows as a stand-alone host, so the connection from Windows is refused.

Add let g:mkdp_open_to_the_world = 1 to init.vim will solve this problem!

I just wanted to mention, using WSL2 (Arch if that makes a difference) the above methods did not work for me.

What DID work was to install wslu and set
g:mkdp_browser=’wslview’
in my vimrc (well, init.vim). I have not experienced the multi-second delays the others are talking about using this approach.

There is my solution：
sudo ln -s /mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe /usr/bin/edge
let let g:mkdp_browser = ‘edge’

I just wanted to mention, using WSL2 (Arch if that makes a difference) the above methods did not work for me.

What DID work was to install wslu and set
g:mkdp_browser=’wslview’
in my vimrc (well, init.vim). I have not experienced the multi-second delays the others are talking about using this approach.

@ndaman it works on my debian wsl2, mostly perfect except that my terminal window will go blank after i start preview, then it gradually reloads everything when i make some mouse or keyboard movement. no big deal but kinda annoying.

@XeonChow it can be solved by using wsl-open instead of wslview . Install wsl-open and set g:mkdp_browser=’wsl-open’

If you prefer a general vim setting to a WSL specified one, use this trick without modifying g:mkdp_browser

Just run :MarkdownPreview and you should be good to go.

@XeonChow it can be solved by using wsl-open instead of wslview . Install wsl-open and set g:mkdp_browser=’wsl-open’

If you prefer a general vim setting to a WSL specified one, use this trick without modifying g:mkdp_browser

Just run :MarkdownPreview and you should be good to go.

@qingbyin
thank yuo so much, i followed your instruction and it works flawlessly.

I didn’t change my ip:port and it works here with an address of http://127.0.0.1:8576/page/1 , although there is still a multi-second delay for it to open. I’m running commit faacfbcefe88badb0a5bee3290ec690373552f2b of this plugin.

I would try disabling Windows defender / firewall to see if that fixes anything.

@XeonChow it can be solved by using wsl-open instead of wslview . Install wsl-open and set g:mkdp_browser=’wsl-open’

If you prefer a general vim setting to a WSL specified one, use this trick without modifying g:mkdp_browser

Just run :MarkdownPreview and you should be good to go.

There is my solution：
sudo ln -s /mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe /usr/bin/edge
let let g:mkdp_browser = ‘edge’

If anyone is looking for a solution that doesn’t require installing wsl-open , modifying your vimrc or creating a symlink you can set up this alias: alias open=»/c/Program Files (x86)/Google/Chrome/Application/chrome.exe»

I’ve been doing this on WSL 2 for months and running :MarkdownPreview works.

I use this plugin in WSL1, ubuntu. Every time I input :MarkdownPreview , the statusline shows » openning ‘http://127.0.0.1:8781/page/5’ . done! (xdg-open)«. And I have to type this address in my browser to view my markdown.

I would like to ask how to make the preview page show automatically? Thank you very much.

@ndaman it works on my debian wsl2, mostly perfect except that my terminal window will go blank after i start preview, then it gradually reloads everything when i make some mouse or keyboard movement. no big deal but kinda annoying.

@XeonChow Another way to solve is to redraw! in the last line of the function pointed by g:mkdp_browserfunc

This is working on WSL2(Ubuntu 22.04) on a x64 machine.
This opens using Chrome by default, and switch to Edge if Chrome not found.

I use this plugin in WSL1, ubuntu. Every time I input :MarkdownPreview, the statusline shows » openning ‘http://127.0.0.1:8781/page/5’ . done! (xdg-open)». And I have to type this address in my browser to view my markdown.

I would like to ask how to make the preview page show automatically? Thank you very much.

@johnsonkee I guess your settings is broken.

When I was testing, I encountered this as well. And it turned out that I made mistakes. Furthermore, even if silent is not used, error messages regarding to the call to browser hide behind vim.

Источник

• Version: 12.16.1
• Platform: Linux eb68db941f4a 5.3.0-1016-aws #17~18.04.1-Ubuntu SMP Fri Mar 27 20:11:52 UTC 2020 x86_64 GNU/Linux
• Subsystem: child_process

What steps will reproduce the bug?

Produced by code that looks like this:

    this.process = spawn(this.command, this.commandArgs, {
      env: this.env,
    });

    this.process.once('exit', this.onProcessExit);
    this.process.stdout.on('data', this.onProcessStdOut);
    this.process.stderr.on('data', this.onProcessStdErr);

1. In an async function, we call child_process.spawn().
2. process.on('uncaughtException') gets triggered with an EGAIN on the attempt to spawn the child process. The stack for this uncaught exception looks like [1]. Note that while the triggering condition was in an async function, it was not converted into a promise rejection as I would have expected. The fact that the following exceptions were reported after, despite having synchronous call-stacks back to our call to spawn makes me think this is happening outside JavaScript-land.
3. Next, we get two identical uncaught exceptions, having a stack originating at our code calling spawn [2]. I suspect these are for stdout / stderr, respectively.

How often does it reproduce? Is there a required condition?

This was produced within a docker container on an ~80% loaded host with several hundred identical containers in operation.

What is the expected behavior?

EAGAIN exceptions thrown by spawn should be handle-able by user-space code and should not produce uncaught exceptions outside normal control flow.

What do you see instead?

As described above, what appears to be an un-handleable exception thrown outside normal control flow.

Additional information

Stack traces:

1:

uncaught exception Error: spawn /usr/local/bin/node EAGAIN
    at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
    at onErrorNT (internal/child_process.js:469:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)

2:

uncaught exception Error: read ENOTCONN
    at tryReadStart (net.js:567:20)
    at Socket._read (net.js:578:5)
    at Socket.Readable.read (_stream_readable.js:478:10)
    at Socket.read (net.js:618:39)
    at new Socket (net.js:372:12)
    at Object.Socket (net.js:263:41)
    at createSocket (internal/child_process.js:314:14)
    at ChildProcess.spawn (internal/child_process.js:437:23)
    at spawn (child_process.js:548:9)
    at SandboxRuntime.spawn (/path/to/out/call/to/spawn.js:123:45)

I also note this comment that makes me suspect the libuv / node-core boundary: #21203 (comment)