xmake-vscode XMake build utility 进程会突然增多导致 VSCode 的 CPU 和内存占用飙升

描述问题

在 VSCode 中编辑代码时会突然变卡顿，打开任务管理器后发现 VSCode 的 CPU 和内存占用很高，且有很多 XMake build utility 进程和 pwsh 进程，如下图所示：

QQ截图20211107155838

QQ截图20211107155933

QQ截图20211107153959

一段时间后整个操作系统都卡死，快速移动鼠标时会触发系统的警报声。

期待的结果

只有少量的 XMake build utility 进程和 pwsh 进程，且不会占用过多的 CPU 和内存资源。

错误信息

无。

其他信息

出问题前有进行过如下操作：

在终端里跑 xmake require --info freetype
从 VSCode 切出，打开 Windows 资源管理器，然后切换回 VSCode

请提供关键的 xmake.lua 配置内容，或者完整 xmake.lua，也可以是其他附加信息帮助我们诊断问题(比如截图，xmake.lua或者可复现的demo)，以及你遇到的问题的一些背景信息。

Nov 07 '21 07:11 lc-soft

有办法复现么，提供下之前的一些操作步骤。。

还有，那个时候有没有在编译或者有编译未完成的任务？xmake.lua 是否在编辑状态？

如果没有编译，应该只有在 xmake.lua 有变动的时候，vscode 插件的 intelligense 会自动执行 xmake 重新生成下 compile_commands ，其他应该不会有进程执行才对。

Nov 07 '21 09:11 waruqi

我已经暂时禁用插件了，有空我再专门花时间测试一下。

Nov 07 '21 13:11 lc-soft

出现了相同的情况 OS: Win10 toolchain: MSVC xmake版本：2.6.7 xmake-vscode版本：1.7.3

xmake.lua

add_rules("mode.debug", "mode.release")
set_toolchains("msvc")
set_languages("c++17")
if is_mode("debug") then
  add_cxxflags("/Zi")
end
add_cxxflags("/utf-8")
set_warnings("all")

add_requires("folly")
add_packages("folly")

set_policy("package.requires_lock", true)

target("untitled")
  set_kind("binary")
  add_files("src/main.cpp")

经过简单对照发现只要删去set_policy("package.requires_lock", true)就没有问题了

复现过程：

默认状态栏即可
点击build按钮多试几次，或无意义的修改一下xmake.lua或main.cpp（只是为了触发xmake重新解析与重新编译，没有试过xmake c -a是否可行）
很容易引发上述现象：随后系统严重卡顿，cpu和内存飙升，之后似乎被操作系统全杀了，系统恢复正常

其他环境参数：自动生成的xmake-requires.lock

xmake-requires.lock

PS C:\Users\xxx> xrepo scan
scanning packages ..
boost-1.79.0:
  -> 380230c42ed042e7b0117a5d3a17de9e: windows, x64
    -> {all=false,atomic=false,chrono=false,container=false,context=false,contract=false,coroutine=false,date_time=false,debug=false,exception=false,fiber=false,filesystem=true,graph=false,graph_parallel=false,iostreams=false,json=false,locale=false,log=false,math=false,mpi=false,multi=true,nowide=false,pic=true,program_options=false,python=false,random=false,regex=false,serialization=false,shared=false,stacktrace=false,system=false,test=false,thread=false,timer=false,toolchains="msvc",type_erasure=false,vs_runtime="MT",wave=false}
  -> 4fcd857a590d49579ea0b9a22bb5b800: windows, x64
    -> {all=false,atomic=false,chrono=false,container=false,context=true,contract=false,coroutine=false,date_time=false,debug=false,exception=false,fiber=false,filesystem=true,graph=false,graph_parallel=false,iostreams=false,json=false,locale=false,log=false,math=false,mpi=false,multi=true,nowide=false,pic=true,program_options=true,python=false,random=false,regex=true,serialization=false,shared=false,stacktrace=false,system=true,test=false,thread=true,timer=false,toolchains="msvc",type_erasure=false,vs_runtime="MT",wave=false}
  -> a496bb8be0034f06a070674d625ccee4: , , empty
bzip2-1.0.8:
  -> 9d437a10afc8444eb49c85bfba26bf4c: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
  -> c4262d8c6fff4b81b1a9a3004a6ef524: , , empty
cereal-1.3.1:
  -> ecfaac8c96b54565acbeb8f85f772ced: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
cmake-3.22.1:
  -> 33174cd752934705b9e583491cc925c6: , , empty
double-conversion-v3.1.5:
  -> 90a2e31c86d345809ef9717d62568526: , , empty
  -> d5f852a9ff9e40b69299b216af0c289c: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
expected-v1.0.0:
  -> 8babd169358a4783a2c046726c49579e: windows, x64
    -> {debug=false,pic=true,shared=false}
fmt-9.0.0:
  -> 1019b565e41d42d1a58c098e385c5549: , , empty
  -> 773b9cfa64fc48cb914c8ae087064068: windows, x64
    -> {debug=false,header_only=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
folly-2022.04.25:
  -> 15eb01ba7a8b42ef8b5cba6a26f2bcb6: , , empty
  -> dc1863106e0c4e8b9da40fc2c03f0305: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
gflags-v2.2.2:
  -> 6d230dc0051c4ea38766c5ba237a1d7a: windows, x64
    -> {debug=false,mt=true,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
  -> b36004dce5104eca99c6a5451320400d: , , empty
glog-v0.5.0:
  -> 0f690093f79143fd820872b81391b4d3: , , empty
  -> a03e498f07034192b36dd37613b83bd5: windows, x64
    -> {debug=false,gflags=true,gtest=false,pic=true,shared=false,toolchains="msvc",unwind=false,vs_runtime="MT"}
libevent-2.1.12:
  -> 3755327dcc544d759ed0516f31b8d7bb: , , empty
  -> 55f41b2c478d412f92cb99a1ea01c5f1: windows, x64
    -> {debug=false,mbedtls=false,openssl=true,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
lz4-v1.9.3:
  -> 5ec245f5e1a041fb9b5fcf7ea280ae92: , , empty
  -> 741669f0df614cf08d64e2a6332a8955: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
nasm-2.15.05:
  -> c3f51b3de3014118ab32f33dbb6626a8: , , empty
openssl-1.1.1q:
  -> 122bf2e537f34e8a954b5296408a9aee: , , empty
  -> cc39de5282a54d92b68a9f7e575021be: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
strawberry-perl-5.32.0+1:
  -> 1676061fab73436b86c8c7ea09a3497e: windows, x64, unused
    -> {debug=false,mingw=false,pic=true,shared=false,vs_runtime="MT"}
zlib-v1.2.12:
  -> a454bc20f209450da098f8baf79a2a6f: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
  -> b5ea843dabd742168c9611e216a46175: , , empty
zstd-v1.5.2:
  -> 1d7fae96dc3c48a6a30ae5672078fe17: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
  -> da573bcc009145e0aa420a05c4691a11: , , empty

虽然不知道有无关联但是有点奇怪的是每一项都有个empty，而且xrepo info pkg_name里的installdir都是empty的安装位置（但是日常确实没有影响。。。）比如：

PS C:\Users\xxx> xrepo scan bzip2
scanning packages ..
bzip2-1.0.8:
  -> 9d437a10afc8444eb49c85bfba26bf4c: windows, x64
    -> {debug=false,pic=true,shared=false,toolchains="msvc",vs_runtime="MT"}
  -> c4262d8c6fff4b81b1a9a3004a6ef524: , , empty
PS C:\Users\xxx> xrepo info bzip2
The package info of project:
    require(bzip2):
      ...
      -> installdir: E:\cpppkg\b\bzip2\1.0.8\c4262d8c6fff4b81b1a9a3004a6ef524

Sep 06 '22 02:09 fonqL

跟这关系不大吧，插件里面会起 xmake 的地方，要么是 build ，要么就是运行 xmake l assets/xxx.lua 脚本获取一些 modes/archs/targets 信息。

我感觉可能是某些 xmake 进程执行，因为用了包，可能触发 -y 输入确认提示，导致一直没能正常退出，否则按理应该很快就会退出才对。。

具体得先看下，是哪些 xmake 进程卡住了，没退出。

可以插件源码里 https://github.com/xmake-io/xmake-vscode/blob/master/src/process.ts 这里加点 logs 调下看看

Sep 06 '22 02:09 waruqi

可能是死循环执行 xmake l update_intellisense.lua 导致。回头我调下。

Sep 06 '22 02:09 waruqi

*追加：不用依赖folly这么复杂的库，依赖一个zlib即可出现问题

Sep 06 '22 02:09 fonqL

如果没任何包呢？

Sep 06 '22 02:09 waruqi

没有任何包时不能复现，而且也没有生成xmake-requires.lock

Sep 06 '22 02:09 fonqL

我这没 win vscode 调试环境，macos 上我试了下，没啥问题么，没法复现问题，你可以直接拉下 vscode 插件源码，加载插件试试，然后提供下调试终端的 logs

Sep 06 '22 14:09 waruqi

确实很奇怪，在wsl环境里我也无法复现。虽然也有突发的cpu涨到100%，但内存没怎么涨，而且cpu也很快就下去了，整个过程也没有卡顿，还挺正常

调试能详细说说吗我不太懂，有时间试试

Sep 06 '22 14:09 fonqL

就是用vscode 打开 xmake-vscode 插件目录，点调试运行就行了。里面加点 log 看看日志就好，然后配置一下 npm 什么的。。

Sep 06 '22 15:09 waruqi

仔细调了一下。感觉是因为windows下插件起的xmake进程退出太慢的原因。在命令行下尝试复现后发现卡住（运行过长时间而不退出，而且也没观察到cpu、网络、磁盘使用）的概率很小，经常是退出太慢，有时需要半分钟到一分钟左右才退出。那问题转移至：为什么会产生大量进程调试插件，产生进程的源头是这里： https://github.com/xmake-io/xmake-vscode/blob/29ab3bbeb8fb834b4fceaa9f6af7be9509169acd/src/xmake.ts#L217-L232 Ubuntu下的插件也有大量产生进程的行为，可能因为系统原因而可以正常运行并没有崩溃 htop截图： htop ubuntu下观察到htop显示的进程数（Tasks）最高到了1370 贴一下两个平台的插件调试时的log windows.txt ubuntu.txt windows下得不到完整的log，只能在崩溃前打下断点暂停并保存log。

附：ubuntu上的复现步骤在可上网的环境中：

xmake create test
cd test，code . 并更改xmake.lua：

add_rules("mode.debug", "mode.release")
set_toolchains("clang")

add_requires("zlib",{system=false})
add_packages("zlib")

set_policy("package.requires_lock", true)

target("test")
  set_kind("binary")
  add_files("src/main.cpp")

保持vscode打开，在命令行下不断重复输入（与是不是vscode内置终端无关）xmake c -avD&&xmake -vD。与windows下百分之百复现不同，linux触发大量xmake进程的概率差不多是4/10。可以拼的更长xmake c -avD&&xmake -vD&&xmake c -avD&&xmake -vD。也可以只重复清理，不重复构建，但是至少要构建一次使xmake-requires.lock文件生成：xmake c -avD&&xmake c -avD&&...，也有很高的复现概率（没测过）。用htop可观察到大量xmake进程

Oct 03 '22 14:10 fonqL

xmake c -a 会强清配置，导致配置每次改动，触发插件内部重新执行 xmake l 更新所有状态，目前是监听 fs watch 配置文件改动，才会执行它

通常只有 xmake f 改配置了，才会执行

为啥需要执行 xmake c -a 这个呢，除非必要不建议这么干

Oct 03 '22 14:10 waruqi

这只是一个复现手段。而且配置改动我觉得十分普遍，换个debug/release模式或者target编译就要改动。

Oct 03 '22 14:10 fonqL

这是因为要同步 xmake 配置状态和状态栏/explore ui，所以通过 fs watcher 去监听配置文件更新，然后通过 xmake l xxx.lua 去加载配置状态信息，目前这是必须的，暂时没其他更好的方案去解决。

主要是 win 下起进程比较重导致容易复现，但只要不频繁切换配置状态，就没事。。

或者可以看看有无其他更好方法可以避免起进程，或者减少子进程调用

Oct 04 '22 13:10 waruqi

是否可以做个判断，.../.xmake/.../xmake.lua不触发更新？我不太知道这些xmake.lua触发更新有何作用？感觉和状态栏与intellisense没什么关系？减少进程的话，不知道进程池之类的是否可行？

Oct 04 '22 14:10 fonqL

Has there been any progress on this? I've been encountering this issue for a year now and I would like to have vscode open while using the terminal.

Feb 23 '23 01:02 qudix

Has there been any progress on this? I've been encountering this issue for a year now and I would like to have vscode open while using the terminal.

No, I have not been able to reproduce it. If you can reproduce it, you can debug the plugin source code directly.

Feb 23 '23 03:02 waruqi

Like this? debug_console.txt

From what I can see it just spams updating Intellisense with exec calls + two others hundreds of times

Feb 23 '23 05:02 qudix

maybe too much onProjectFileUpdated events, I will try to import it.

Feb 23 '23 05:02 waruqi

That does seem to be the case, as a test if I temporarily comment out loadCache updateIntellisense and leave xmakeExplorer.refresh(), the number of verbose logs is the same as the number of processes. With all 3 I get 3 times the number of processes, at least it would if it didn't die at 1219 processes.

Feb 23 '23 06:02 qudix

The _projectFileSystemWatcher currently watches for all xmake.lua files, including those inside the workspace .xmake folder.

I don't know how globs work in js, but my crude attempt at excluding the .xmake folder essentially "solves" the problem for me.

This doesn't solve the underlying issue however, hypothetically if my project had 100 xmake.lua files and they were all updated at once, it would spawn 300 processes.

Feb 23 '23 06:02 qudix

Like this? debug_console.txt

From what I can see it just spams updating Intellisense with exec calls + two others hundreds of times

I have fixed it. 1.9.5

Feb 24 '23 03:02 waruqi

自动生成的xmake-requires.lock

我修复了，应该就是这个问题，开启 xmake-requires.lock 后，会 clone 整个 xmake-repo 副本到 .xmake 下面，里面的大量 xmake.lua 都被 watch 了，所以会触发大量的更新事件，执行大量的 xmake 子进程去生成 compile_commands.json

Feb 24 '23 03:02 waruqi

xmake-vscode
xmake-vscode copied to clipboard

XMake build utility 进程会突然增多导致 VSCode 的 CPU 和内存占用飙升

描述问题

期待的结果

错误信息

相关环境

其他信息

xmake-vscode xmake-vscode copied to clipboard

XMake build utility 进程会突然增多导致 VSCode 的 CPU 和内存占用飙升

描述问题

期待的结果

错误信息

相关环境

其他信息

xmake-vscode
xmake-vscode copied to clipboard