[bug] nasm 惰性自举时序:构建先于 bootstrap 完成而判死(.asm 冷环境必失败) #232

Activity

1. Sunrisepeak commented on Jul 17, 2026

   

   Sunrisepeak

   on Jul 17, 2026

   MemberAuthor

   More actions

   补充:本地复现把根因往下挖了一层 —— 不是时序问题,是 xim:nasm 安装本身产出空载荷。

   ensure_nasm(src/xlings.cppm)是严格同步的:PATH 探测 → 阻塞式 install_with_progress(env, "xim:nasm") → 重新 find_sandbox_nasm → 全空才报错。日志里 error 先于 "Bootstrap nasm" 出现只是 ui 缓冲交错(status 走缓冲通道、error 直写),不存在"先判死后补装"的竞态。

   真正的断点(本地 100% 复现,linux x86_64):

   export XLINGS_HOME=<fresh-dir>            # 从 mcpp-0.0.95-linux 发行包拷贝 registry
   <vendored>/bin/xlings install xim:nasm -y  # 输出 ✓ 1 package(s) installed,rc=0
   

   之后:

   • data/xpkgs/xim-x-nasm/3.02/ 只有 .xim-installed + .xpkg.lua,没有 nasm/ndisasm 二进制;
   • subos/default/bin/nasm shim 已创建但悬空(nasm -v 无输出);
   • 所以 find_sandbox_nasm 探测 <ver>/nasm、<ver>/bin/nasm 找不到是正确行为 —— 载荷根本不存在。

   嫌疑机制:xim-pkgindex pkgs/n/nasm.lua 的 hook

   function install()
       os.tryrm(pkginfo.install_dir())
       os.mv("nasm-" .. pkginfo.version(), pkginfo.install_dir())
       return true
   end

   与新版 xlings 安装器的 C++ 侧 stage_extracted_payload_(下载解压后自动把载荷搬进 install_dir)叠加:C++ 先 staged → hook 的 os.tryrm 把已就位的载荷删掉 → cwd(runtimedir)里 nasm-3.02 已被搬走,os.mv 落空 → 仍返回 true → xlings 标记安装成功并建 shim。

   建议修复方向(择一或并行):

   1. xim-pkgindex:nasm.lua 的 install() 改为幂等(载荷已在 install_dir 时直接 return true),这是最小改动;同类 "tryrm+mv" 手写 hook 的包需要排查。
   2. xlings:hook 返回 true 但 install_dir 为空(或 xvm shim 指向不存在的 bindir)时判失败,别让空安装标记成功——这是防同类问题的系统性修法。
   3. mcpp ensure_nasm:find_sandbox_nasm 复查失败时把 xlings install 的输出转发出来,别只留一句 "not installable"。

   另:CI 侧 mcpp-index 已恢复 apt nasm(f2f7e08)作为临时措施,此 issue 修复后即可移除。
2. Sunrisepeak

   added a commit that references this issue on Jul 18, 2026

   fix(nasm): XLINGS_RES placeholder + hardened install hook (mcpp#232) (#…

   ...

   cf97bc6
3. Sunrisepeak commented on Jul 18, 2026

   

   Sunrisepeak

   on Jul 18, 2026

   MemberAuthor

   More actions

   Root cause confirmed (supersedes my earlier hook-vs-staging theory)

   The empty install is an index-side descriptor bug, now fixed in openxlings/xim-pkgindex#398:

   nasm.lua (from xim-pkgindex#395) declared its resources with the new xpm.source = "xlings-res" + per-arch sha256 table form. Deployed xlings engines parse neither the source key nor a table-valued sha256 — the resolved resource ends up with no URL, so no download is ever planned. Reproduced with the xlings vendored in mcpp 0.0.95 (fresh XLINGS_HOME, verbose): no Download/Extract phase, runtimedir/ empty, then:

   1. install hook runs: os.mv("nasm-3.02", install_dir()) — source dir doesn't exist, no-ops; hook still return true
   2. xlings auto-stamps .xim-installed into the empty dir → "1 package(s) installed ✓"
   3. config() registers xvm shims pointing at nothing → dangling subos/default/bin/nasm

   Fix landed (index side): xim-pkgindex#398 switches nasm.lua to the production-proven mcpp.lua idiom — url = "XLINGS_RES" placeholder + arch-keyed sha256 (ignored by old engines, verifiable by new ones) — and hardens install() to be idempotent and to fail loudly when the binary isn't in place instead of returning true over an empty dir. Verified against the vendored 0.0.95 xlings: download happens, nasm --version → 3.02.

   Remaining mcpp-side gap (why 0.0.96 is still affected out-of-the-box)

   ensure_nasm calls install_with_progress(env, "xim:nasm", ...) directly, with no index-freshness call — and even ensure_official_package_index_fresh wouldn't help here: it is offline-first and returns early when the package file exists locally. The xim-pkgindex snapshot vendored inside the mcpp 0.0.96 release archives predates the fix, so the broken nasm.lua is used as-is until the user happens to run xlings update / mcpp index update.

   Suggestions:

   • next mcpp release: vendor a post-feat: converge template selectors, runtime binding, graphics contract, and mcpp-bin AUR #398 index snapshot (sufficient by itself);
   • more robust: when a bootstrap install reports success but the sandbox probe (find_sandbox_nasm) still finds nothing, force one index refresh and retry once — that would have both surfaced and healed this failure mode;
   • xlings: refuse to auto-stamp .xim-installed over an install whose hook moved nothing and whose download plan was empty (a package with programs declared but an empty install dir is almost certainly a failure, not a wrapper package).

   CI note: mcpp-index keeps its apt-get install nasm step until a mcpp release ships with the fixed vendored snapshot.
4. Sunrisepeak commented on Jul 18, 2026

   

   Sunrisepeak

   on Jul 18, 2026

   MemberAuthor

   More actions

   ✅ 已在 mcpp 0.0.97 修复(PR #236,482b428,簇 F)。

   nasm 供给改走工具链同款同步门 Fetcher::resolve_xpkg_path("xim:nasm@3.02", autoInstall=true)(索引刷新前置 + 阻塞安装 + payload 校验 + 硬报错),不再先判死后台补装;get_cfg() 的 config 自举错误不再被吞成误导性的 "no usable nasm"。

   验证:单测(find_usable_nasm 6 例矩阵 + 错误不吞)+ e2e 105_asm_sources_nasm.sh 冷环境分区。
5. Sunrisepeak

   closed this as completedon Jul 18, 2026