Zulip Chat Archive
Stream: lean4
Topic: Many Lean processes on Windows
Floris van Doorn (Jul 24 2025 at 15:42):
Can someone on Windows test the following:
- Open Task Manager
- Create a new file in Mathlib with the following contents and wait for Lean to finish compiling the file
import Mathlib
#check Ring
#check Field
#check Module.Finite
#check IsArtinian
#check Module.Free
- I now have 2 visible processes
lean.exein the task manager - Jump to the definition of
Ring, which opens in a new file, and wait for that file to finish compiling - Close the new tab
- Repeat steps 4-5 for all other definitions.
- Check how many processes
lean.exeare running in the task manager
After each iteration of steps 4-5, I get one additional Lean executable running in the task manager, so at the end, lean.exe is running ~7 times. I am on Lean v4.22.0-rc3.
Floris van Doorn (Jul 24 2025 at 15:45):
After multiple such tasks, Lean can slow down significantly (probably because they are competing for CPU/Memory).
Floris van Doorn (Jul 24 2025 at 15:46):
Something that I couldn't quite make reproducible, but also had happen to me a few times: the task in my main editor stopped responding at all (the "yellow bar" wouldn't move past simple commands like a variable or attribute or set_option command, even after giving it 10+ seconds).
This happened when I was browsing the output of trace/profiler commands, sometimes jumping to definitions, sometimes editing the file a bit. (EDIT: posted this here #lean4 > Lean freezes with `#count_heartbeats` )
Marc Huisinga (Jul 24 2025 at 16:00):
I tried this on a Windows machine but can't seem to reproduce that the processes linger around after closing the tab.
Floris van Doorn (Jul 24 2025 at 16:08):
Hmm... Do you have any ideas how I could help diagnose this further (post logs, ways to try to minimize this behavior, or maybe I should try it on a fresh copy of Mathlib or something)?
Floris van Doorn (Jul 24 2025 at 16:26):
FWIW, I can still reproduce it without importing any Mathlib files (this is still a file in the Mathlib directory of my local copy of Mathlib:
import Lean
#check Nat
#check Int
#check Lean.MetaM
#check Lean.Parser.adaptCacheableContext
Marc Huisinga (Jul 24 2025 at 16:32):
(FWIW, I checked with a recent Mathlib on v4.22.0-rc4, probably good to double-check on that one first)
I think the first thing to check would be whether the language server gets the correct messages from VS Code. Set 'Lean 4 > Trace: Server' to 'compact', restart VS Code without any open tabs, open the Lean output window (command: 'Show Troubleshooting Output') and repeat your reproduction up to the step where you've closed the file for Ring and a process that shouldn't be there anymore is still sticking around. There should be a bunch of output in the 'Lean: Editor' panel that would be helpful to know about.
You could also try whether using gdb works on Windows (I think it's shipped with e.g. mingw) and then we can try looking at the backtraces.
- Get your reproduction into the state where you have three processes, one of which shouldn't be there (for the closed tab).
- Figure out the process ID (pid) of all of your
leanprocesses (e.g. using the "Resource Monitor" on Windows) - One after another, run
gdb -p <pid>for each of these process ID, and thenthread apply all btingdbto get the backtraces. Copy each set of backtraces and then usequitto leave eachgdbsession.
Floris van Doorn (Jul 24 2025 at 16:44):
Ok, going through the steps:
I can still reproduce this on Lean v4.22-rc4.
Floris van Doorn (Jul 24 2025 at 16:57):
Here is the server trace file: https://gist.github.com/fpvandoorn/7e26b87fadde89db2e5432b6be99ae1a
I believe I closed the secondary file (Lean.Parser.Attr) at 6:53:44, and afterwards, I still see keepAlive notifications.
Floris van Doorn (Jul 24 2025 at 17:09):
Here is the output of gdb, of what I think is the process that shouldn't be there:
https://gist.github.com/fpvandoorn/8a4fa6c179053d5a0b7123e0fae6318f
Here is the output of gdb of another run with all three processes: (I think the second one, starting at line 273, is the one that shouldn't be there)
https://gist.github.com/fpvandoorn/e743b5e952345bf5f0928499876dd89d
Floris van Doorn (Jul 24 2025 at 17:09):
I hope this helps!
Marc Huisinga (Jul 25 2025 at 09:41):
Oh, interesting. I'm glad I asked for the LSP log - the client never emits a didClose notification for the document for some reason, so the server doesn't know to terminate the process.
It probably isn't the cause of the issue, but could you also ensure that both VS Code and the extension are up-to-date? The most recent VS Code version is 1.102.2 and the most recent extension version is 0.0.209.
Marc Huisinga (Jul 25 2025 at 09:43):
(I'd also be curious if anyone else with a Windows system can reproduce this / not reproduce it)
Marc Huisinga (Jul 25 2025 at 09:45):
Another shot in the dark: Are you running any other VS Code extensions? Does disabling them make a difference?
Sébastien Gouëzel (Jul 25 2025 at 09:57):
I just tried it on my windows system (windows 11, mathlib and vscode up to date), and I can't reproduce: when I close a tab, a Lean process disappears.
Floris van Doorn (Jul 25 2025 at 13:38):
I did update VSCode this morning. I now have the versions you mentioned for VSCode and the extension, and the issue still persists.
The issue also persists after disabling all extensions except the Lean 4 extension. (EDIT: this was false)
Marc Huisinga (Jul 25 2025 at 13:39):
Argh. I assume your settings.json doesn't contain any non-standard settings, either? (Settings > "Open Settings (JSON)" in the top right)
Marc Huisinga (Jul 25 2025 at 13:42):
(If that's not it either, I'll see if I can build you a custom version of the extension that produces more debug output)
Marc Huisinga (Jul 25 2025 at 14:52):
When debugging further, we found out that this problem is caused by the fairly common "GitHub Pull Requests" extension. If you have it installed, I'd recommend disabling it and restarting VS Code afterwards.
This issue is also independent of Windows, and running it myself while working on a TypeScript project caused some other strange bugs (e.g. issues in the "Problems" view for TypeScript wouldn't clear when closing the file, as it usually does).
I'm 90% sure that this issue is independent of Lean; VS Code will simply not emit any more didClose events for certain files when using this extension.
Floris van Doorn (Jul 25 2025 at 17:10):
Would it make sense to open an issue in their repo?
Marc Huisinga (Jul 25 2025 at 19:13):
I've created https://github.com/microsoft/vscode-pull-request-github/issues/7403
Last updated: Dec 20 2025 at 21:32 UTC