crash because of unexpected pending file io on windows

[hpcfzl]

Zig Version

0.16.0

ZLS Version

0.16.0

Client / Code Editor / Extensions

Lite XL on Windows

Steps to Reproduce and Observed Behavior

1. Download Lite XL and the lsp plugin
2. Add the following init.lua file in the user directory, assuming you already have zls on PATH:

   local lspconfig = require "plugins.lsp.config"
   lspconfig.zls.setup()

3. Open a Zig file
4. Crash

Expected Behavior

So I'm updating to use the newer ZLS v0.16.0 alongside Zig v0.16.0.

However there's a problem which is causing ZLS to instantly crash.

The editor itself is otherwise still completely functional.

Here's Lite XL's log.txt:

• See PastedText.txt
• I applied all my insights, mentioned further below, to obtain as much logging as possible here

What I have tried so far is:

• disabling all plugins (lsp still seems to turn on automatically because of ./user/init.lua)
• resorting to:
  • opening only an empty Zig file
  • using a minimal ./user/init.lua:

    local lspconfig = require "plugins.lsp.config"
    lspconfig.zls.setup()

• enabling more error logging by:
  • building a -Doptimize=Debug ZLS v0.16.0 binary from source
    • the only difference by doing this that I noticed is ... (debug) in the logging, as opposed to ... (info)
  • enabling the --enable-stderr-logs flag as seen in zls --help, inside .../lsp/config.lua

    lspconfig.zls = add_lsp {
      ...
      command = { '.../zls', '--enable-stderr-logs' }, -- This is as mentioned
      verbose = true -- Additionally, this enables seeing all LSP communication JSON
    }

  • enabling Lite XL's standard error logging option for the lsp plugin, via ./user/init.lua here

    ...
    local config = require "core.config"
    config.plugins.lsp.log_server_stderr = true

At least three Lite XL users have been able to run ZLS in Lite XL on Linux, having altered two lines of code in .../lsp/server.lua to avoid crashes. To clarify, I also tried doing that, without success.

I have been searching for similar issues since and found #1442 to be the most similar to mine, however changing / to \\ and adding .exe to the ZLS binary path didn't help.

Attach ZLS log output

This is zls.log, seems like a summarised log.txt

info  ( main ): Starting ZLS      0.16.0 @ '.../zls'
info  ( main ): Log File:         ...\AppData\Local\Temp\zls\zls.log (debug)
info  (server): Client Info:      Lite XL (2.1.8)
debug (server): Offset Encoding:  'utf-16'
info  (server): added Workspace Folder: file:///... (969 files)

The '.../zls' is the absolute path to the ZLS binary. Adding ZLS to PATH and using 'zls' instead made no difference.

[hpcfzl]

There is now a fix related to FILE_FLAG_OVERLAPPED pending to be added into Lite XL.

[Jan200101]

I've had the misfortune of nerd-sniping myself with this but here is a breakdown of what went wrong:

Lite-XL spawns a process with pipes for STDIO so that it can access the outputs and provide input if needed, this was done with FILE_FLAG_OVERLAPPED to allow the editor to read and write when it has spare time without being blocked or needing to spin up a new thread.

Because of this when ZLS tried to read from STDIO it ended up calling NtReadFile on a OVERLAPPED handle which gave the result PENDING which Zig routed into unreachable because it was not aware the handle was async.

Fix in Lite-XL: lite-xl/lite-xl#2226
I'm considering opening a discussion somewhere on the ZSF Zulip to see if its worth dealing with or if programs should simply not make stupid decisions.

[Masken3]

I encountered this bug with Textadept's LSP module, on Windows.

Workaround: use cat as an intermediary. In init.lua:
lsp.server_commands.zig = 'cmd /C cat | zls'

[Jan200101]

textadept-lsp implements their own os.spawn function in Lua which then calls the spawn method of a given frontend.

The Qt frontend which makes use of QProcess to implement this functionality but Qt only makes use of standard pipes instead of overlapped ones.

The curses frontend makes use of reproc which specifically avoids non blocking

Are you sure this is the same issue?

[Masken3]

I am not sure. I guessed, based on NtReadFile, OVERLAPPED and unreachable in this log:

Starting language server: zls
INFO: Starting ZLS      0.16.0 @ 'zls'
INFO: Log File:         C:\Users\foobar\AppData\Local\Temp\zls\zls.log (info)
INFO: Loaded config:    C:\Users\foobar\AppData\Local\zls.json
INFO: Client Info:      textadept (Textadept 12.9)
nil: Offset Encoding:  'utf-16'
Connected to zls 0.16.0
thread 15328 panic: reached unreachable code

/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Threaded.zig:9735: 0x7ff71978d907 in ntReadFileResult (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Threaded.zig:9726: 0x7ff71978d907 in fileReadStreamingWindows (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Threaded.zig:9585: 0x7ff71978d907 in fileReadStreaming (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Threaded.zig:2547:53: 0x7ff71978d907 in operate (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io.zig:453: 0x7ff719753de8 in operate (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/File.zig:475: 0x7ff719753de8 in readStreaming (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/File/Reader.zig:283:35: 0x7ff719753de8 in readVecStreaming (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/File/Reader.zig:236:65: 0x7ff719753b4b in readVec (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Reader.zig:1135:29: 0x7ff71975c317 in fillMore (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Reader.zig:831:21: 0x7ff71975c06b in peekDelimiterInclusive (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/Io/Reader.zig:803: 0x7ff719a3203c in takeDelimiterInclusive (zls_zcu.obj)
/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:976: 0x7ff719a3203c in parse (zls_zcu.obj)
/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:1312: 0x7ff719a3203c in readJsonMessage (zls_zcu.obj)
/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:1125:39: 0x7ff719a3203c in readJsonMessage (zls_zcu.obj)

/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:1142: 0x7ff719a31c2a in readJsonMessage (zls_zcu.obj)

/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:1279:60: 0x7ff719a31c2a in readJsonMessage (zls_zcu.obj)

/home/runner/work/zls/zls/zig-pkg/lsp_kit-0.1.0-bi_PL3IyDACfp1xdTnkiOHEok2YpPCCCJHuuOcNzjl1D/src/lsp.zig:1142: 0x7ff7197464b2 in readJsonMessage (zls_zcu.obj)

/home/runner/work/zls/zls/src/Server.zig:1758: 0x7ff7197464b2 in loop (zls_zcu.obj)
/home/runner/work/zls/zls/src/main.zig:597:20: 0x7ff7197464b2 in main (zls_zcu.obj)

/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/start.zig:699: 0x7ff719749766 in callMain (zls_zcu.obj)
/home/runner/work/_temp/3bb3a68a-55de-43a1-97d0-5c8ca8845796/zig-x86_64-linux-0.16.0/lib/std/start.zig:485:17: 0x7ff719749766 in WinStartup (zls_zcu.obj)
???:?:?: 0x7ff9f1c27343 in ??? (KERNEL32.DLL)

???:?:?: 0x7ff9f26a26b0 in ??? (ntdll.dll)

Server exited with status 3

[Jan200101]

Looking further into it Qt does create async pipes in some cases (which I find completely horrifying).
There is nothing ZLS can really do here so I'm opening a discussion for Zig on the ZSF Zulip.

[Jan200101]

Upstream issue

https://codeberg.org/ziglang/zig/issues/35603