emrun always exits (Windows)

[aardappel]

On Windows, running emrun --browser chrome mywasm.html --verbose quits immediately after launching the page, so is presumably not running the local webserver, and not surprisingly the page shows Failed to load resource: net::ERR_CONNECTION_REFUSED errors in the console. No errors on the command line.

Tried to force it to not quit by adding --serve_after_close, which did not change anything.

Probably not related, but still odd, if instead of the above command line I run just emrun mywasm.html, I get:

No module named 'win32api'
Importing Python win32 modules failed! This most likely occurs if you do not have PyWin32 installed! Get it from https://github.com/mhammond/pywin32/releases
Traceback (most recent call last):
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 1767, in <module>
    sys.exit(main())
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 1759, in main
    returncode = run()
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 1614, in run
    browser = find_browser(str(options.browser))
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 1130, in find_browser
    return win_get_default_browser()
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 1110, in win_get_default_browser
    import_win32api_modules()
  File "C:\stuff\emsdk\upstream\emscripten\emrun.py", line 116, in import_win32api_modules
    import win32api
ModuleNotFoundError: No module named 'win32api'

[Akaricchi]

This happens to me on Linux too when chromium is already running, so it opens the page in the existing session and the emrun-invoked chromium process just exits. I use --no_browser as a workaround and then open the page manually.

[aardappel]

@Akaricchi thanks! Works normally for me on Linux. --no_browser is a good enough workaround for Windows for now. If its a problem of the process exciting, then I am surprised --serve_after_close doesn't fix it.

[lpotter]

When the sdk changed urls, the python package was also changed and it no longer downloads a version that contains the win32api. This affects running wasm apps from Qt Creator.

[kripken]

@lpotter that sounds like a separate issue from this one (which is about emrun), unless I'm not seeing the connection? If it's separate please file a new issue with the relevant details (which urls, which versions).

[sbc100]

Ah! Good catch. I guess we need to ship win32api somehow.

[sbc100]

The same bug on the emsdk side: emscripten-core/emsdk#458

[lpotter]

Seems to happen on all platforms - mac, linux and windows.

[tjachmann]

Same problem here, emrun always quits with win32api missing.

The workaround solution for me was, to delete the python directoy in the emsdk. This way my global python installation was used by emscripten. Then I could manually install pywin32, which contains the win32api. This can be done by using pythons pip:

pip install pywin32

[boenkemeyer]

I tested this with a few browsers and came to this conclusion:

After emrun spawned the new process, it waits for that process to terminate. If there already is an open browser window, the newly started process delegates creating a new tab/window (and usually another process we don't have the pid of) to the running process group and exits. emrun will then terminate prematurely.

There is a mechanism built into emrun.py that makes an attempt to figure out the actual new pid. This mechanism silently fails if the psutil module is not installed.

I suggested a warning message as mitigation if psutil cannot be imported. (#10984)

However, there are a few workarounds to solve the issue:

• Install psutil:

Make sure to install the module in the correct python instance used. Change to the emsdk/upstream/emscripten directory, and do python -m pip install psutil

• Kill existing browser processes or don't start a browser process at all:

A very simple workaround is to kill all existing browser processes or use --no_browser. You'll have to open the browser and url manually.

• Have the browser call create a new process and keep it:

For google chrome and chromium, the following workaround can do the trick:

Command-Line Option to open new chrome process group

for Win:

emrun --browser chrome --browser_args '--user-data-dir="%temp:\=\\%\\emrun"' foo.html

for Linux:

./emrun --browser chrome --browser_args '--user-data-dir="/tmp/emrun"' foo.html

The other issue mentioned by the OP could be connected to pywin32 not being installed in the right python instance. To make sure pywin32 is installed correctly:

Change to the emsdk/upstream/emscripten directory, and do python -m pip install pywin32.

[aardappel]

Additionally, when you use the --no_browser workaround, it outputs Now listening at http://0.0.0.0:6931/ which is incorrect, the ip should be localhost.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.