Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#830 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
18/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
git, nodejs, rust, shell
Domínio
build-system, devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
473
Forks
44
Merge médio
1d 1h
PRs com merge (30d)
63

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/vite-task

Todas as issues de voidzero-dev/vite-task

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.