Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Windows: automatic filesystem tracking makes Git/MSYS sh.exe fail with MapViewOfFileEx error 487

Đang mở
  • Có gì không ổn?
#830 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
18/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
git, nodejs, rust, shell
Lĩnh vực
build-system, devtools

Hướng nghiên cứu

Start with crates/fspy/src/windows/mod.rs and crates/fspy_preload_windows/src/windows/detours/create_process.rs, where the tracking DLL is injected into suspended processes and propagated to children. Then check ExecutionMode::build in crates/vt/src/session/execute/mod.rs to see when fspy is enabled. Reproduce with the probe files in the issue and vp run --cache probe. Done would mean Git/MSYS sh.exe starts cleanly under automatic tracking, verified by the probe exiting 0.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

On Windows, a cache-enabled vp run using automatic filesystem tracking causes Git for Windows sh.exe to fail during startup with:

*** fatal error - MapViewOfFileEx 'shared.5'(0x11C, size 59320, m 0, created 0), Win32 error 487. Terminating.

The same Node program and shell succeed with caching disabled. Importantly, caching itself is not the incompatible part: a task with explicit inputs and outputs executes successfully and subsequently returns a cache hit, without the automatic tracking injection.

This reproduces in a standalone directory with no application code, test runner, dependencies, or parallel workers. It reproduces when launched from either PowerShell or Git Bash.

Environment

  • Windows 11 Pro, build 26200
  • Vite+ global and local CLI: 1.0.0
  • Node.js: 26.10.0
  • Git for Windows: 2.55.0.windows.3
  • sh resolves to C:\Program Files\Git\usr\bin\sh.exe

These are the versions tested; I have not established the first affected release.

Standalone reproduction

Create these files in a fresh directory. An existing Windows Vite+ installation and Git for Windows on PATH are sufficient; no package installation is needed for this reproduction.

package.json

{
  "name": "msys-mapview-repro",
  "private": true,
  "scripts": {
    "probe": "node probe.cjs"
  }
}

pnpm-workspace.yaml

packages: []

vite.config.js

module.exports = {
  run: {
    cache: { scripts: true, tasks: true },
    tasks: {
      'probe:explicit': {
        command: 'node probe.cjs',
        cache: { input: ['probe.cjs', 'probe-input.txt'], output: [] },
      },
    },
  },
};

probe-input.txt

first-input

probe.cjs

const { spawnSync } = require('node:child_process');
console.log(JSON.stringify({
  node: process.version,
  FSPY: process.env.FSPY ?? null,
}));
let failures = 0;
for (const [label, command] of [
  ['direct', 'printf shell-ok'],
  ['nested', 'sh -c "printf nested-ok"'],
  ['forks', 'for i in 1 2 3; do sh -c "printf fork-ok"; done'],
]) {
  const result = spawnSync('sh', ['-c', command], {
    encoding: 'utf8',
    timeout: 10000,
  });
  console.log(JSON.stringify({
    label,
    status: result.status,
    error: result.error?.message,
    stdout: result.stdout,
    stderr: result.stderr,
  }));
  if (result.status !== 0 || result.stderr !== '') failures++;
}
process.exitCode = failures ? 1 : 0;

Run these commands from that directory:

node probe.cjs
vp run --no-cache probe
vp run --cache probe
vp run probe:explicit
vp run probe:explicit

Expected and actual behavior

Command Observed result
node probe.cjs All three shell launches succeed; FSPY is absent.
vp run --no-cache probe All three shell launches succeed; FSPY is absent.
vp run --cache probe FSPY=1; all three shell launches fail before their commands execute, with the MapViewOfFileEx error.
First vp run probe:explicit All three shell launches succeed; FSPY is absent.
Second vp run probe:explicit Successful output is replayed with cache hit.

The failing shell processes return 3221225794 (0xC0000142, DLL initialization failure). The probe therefore exits 1. A single spawnSync('sh', ['-c', 'printf shell-ok']) is sufficient to trigger the error; the other two cases are controls, not required concurrency or nesting.

Changing the explicitly declared probe-input.txt invalidates the explicit task cache and the task executes successfully again. The probe does not read this file: it is deliberately declared as a synthetic cache input to check invalidation.

Setting FSPY=1 manually while running the program directly also succeeds, so the environment marker alone is not the trigger.

Investigation

The A/B results isolate the automatic filesystem-tracking path. In the source inspected at revision 7d69d6577ecf6bd83deee32186de59918a712873:

MSYS is sensitive to its virtual-address layout and shared-memory mappings. That explains the class of failure, but I have not proven which allocation or hook causes the mapping failure inside the injected process. This report does not assume a particular native fix or claim that Windows Mandatory ASLR is the cause.

Impact and request

Cached commands that start Git/MSYS shell programs fail during child startup, even when the shell commands are trivial. Script and test harnesses that launch many such processes can emit many copies of the fatal error.

Disabling caching avoids the failure but loses cache replay. Explicit dependency declarations preserve caching and are a useful bridge, but require maintaining complete inputs and outputs. Please investigate compatibility between Windows automatic tracking/DLL injection and Git/MSYS startup, ideally retaining sound dependency tracking rather than silently skipping these processes.

AI attribution: This report was written by an AI coding assistant. The standalone reproduction and cache/no-cache comparisons were executed on the affected Windows machine; observations are distinguished above from the unverified native-level explanation.

Ngôn ngữ chính
Rust
Star
473
Fork
44
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
63

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/vite-task

Tất cả issue của voidzero-dev/vite-task

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.