Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#830 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, nodejs, rust, shell
Área
build-system, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
473
Forks
44
Merge medio
1 d 4 h
PR fusionados (30 d)
73

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de voidzero-dev/vite-task

Todos los issues de voidzero-dev/vite-task

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.