Node.js 23/24 linux-x64 build ships a dedicated `lpstub` PT_LOAD segment
aligned to 2 MiB (0x200000) so that, at startup the binary can remap its
.text region onto Linux hugepages for an iTLB win `--use-largepages=mode`.
WSL1 `binfmt_elf` strictly rejects any PT_LOAD whose `p_align`
exceeds the system page size (0x1000); the kernel returns ENOEXEC and the
shell reports "exec format error" before user space ever runs. This breaks
launching the bundled Node from the VS Code server under WSL1 starting
with Node 24.
The fix does not change runtime behavior:
- Node is a non-PIE EXEC binary with fixed virtual addresses
(`p_vaddr`, `p_paddr`); the loader maps each PT_LOAD at its
hard-coded address regardless of `p_align`, which on EXEC is
metadata describing alignment in memory rather than a request to
relocate.
- The hugepage optimization itself is performed at runtime
against the live mapping; it does not consult `p_align` and
is unaffected by this change.
- No shared libraries, native addons, or dynamic linker paths are
touched — only PT_LOAD segments inside the node executable itself.
The Linux desktop sanity tests (deb/rpm/snap) ran cleanup unconditionally
after `testDesktopApp` without a try/finally, so when that step threw
(e.g. extension install flake tracked in microsoft/vscode-engineering#2877)
the uninstall step was skipped. Mocha then retried the test, the install
step hit `package code-insiders is already installed`, and the retry
masked the real failure with a misleading error
(microsoft/vscode-engineering#2878).
Fix:
- Wrap install/test/uninstall in try/finally so cleanup runs even when
the test body throws.
- Make the uninstall helpers idempotent by detecting whether the package
binary exists; this lets the finally block run safely even if install
itself fails (and avoids double-uninstall on the happy path).
- Add a pre-install assertion to each install helper that fails fast
with a clear diagnostic when the package is already present, so any
leftover state from a prior killed run surfaces as a real bug pointing
at the prior failure instead of as a confusing `rpm -i` /
`dpkg -i` / `snap install` error.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Recurring transient failures of the desktop-linux-arm64 sanity test
surface only as 'Failed to install extension after 3 attempts' with no
context. This makes diagnosis hard.
- Carry the last per-attempt failure message into the final thrown error
- Capture a screenshot on each failed install attempt
- Log any visible Marketplace message during failed install attempts
- Add a 5s backoff between install retries
Refs microsoft/vscode-engineering#2877
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace @vscode/ripgrep with @vscode/ripgrep-universal which bundles all platform binaries in a single package. Non-target platform binaries are stripped at packaging time via getRipgrepExcludeFilter.
- Add shared rgDiskPath() helper in src/vs/base/node/ripgrep.ts
- Convert all ripgrep consumers to use the async helper
- Add getRipgrepExcludeFilter for build packaging
- Update prepareBuiltInCopilotRipgrepShim for new bin layout
- Update eslint allowed-modules and require-interceptor aliases
- Fix platform mapping for Alpine + armhf
- Handle arch-specific binaries in macOS universal build / verify-macho
Per discussion in today's engineering infra sync, drop the mocha-level retry count on the two sanity-test runners from 3 to 1. A single retry is enough to absorb transient flakes without masking real regressions or significantly inflating runtime when a test is genuinely broken.
* Force-kill Electron app if close hangs in sanity tests
When a renderer crash occurs mid-test, app.close() can hang for the entire mocha timeout (~10 min), turning a single failed test into a partially-succeeded build. Add a closeElectronApp helper that races close() with a 60s timeout and falls back to killProcessTree.
* Address review: clear timeout, guard force-kill
Clear the race timeout when app.close() resolves quickly so it does not keep the event loop alive, and wrap killProcessTree in try/catch so a failure during force-kill does not mask the original test failure.
* Only dismiss the welcome dialog in sanity tests if it is shown
Co-authored-by: Copilot <copilot@github.com>
* Remove Agents app validation on Linux
* Don't run Agents app tests on stable
Co-authored-by: Copilot <copilot@github.com>
* Keep Agents app testing, but disable validation instead.
* Disable agents app test for stable builds
---------
Co-authored-by: Copilot <copilot@github.com>
* fix: restrict onboarding to first-launch users and fix sanity tests
- Add isNew(StorageScope.APPLICATION) guard to only show onboarding for
genuinely new users, not existing users upgrading
- Move all guard conditions into tryShowOnboarding() for clarity
- Change ONBOARDING_STORAGE_KEY scope from PROFILE to APPLICATION
- Add --skip-welcome to sanity test Electron launch args to prevent
onboarding overlay from blocking workspace trust dialog
Fixes onboarding showing for existing users and sanity test timeouts
introduced by PR #307262.
* use getBoolean for ONBOARDING_STORAGE_KEY check
* Add WSL sanity tests
* Ensure WSL is installed and ready in Windows test script
* Try to get Ubuntu WSL installed if not present
* Use correct URL
* Fix win32 setup script
* Script update
* Another script fix
