Linux x64 prebuild 1.0.29-preview.1: runtime.node now needs shared OpenSSL and aborts under VS Code snap RPATH (core20 glibc 2.31 vs host libcrypto.so.3 requiring GLIBC_2.38)

Aberta
#2,897 2 comentários 1 reação 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
github, linux, node.js
Domínio
backend, devops

Direção de pesquisa

Start by comparing the Linux x64 prebuild’s runtime.node and copilot-runtime with the working prebuilds named in the report; inspect their DT_RPATH and OpenSSL dependencies using readelf and ldd. Reproduce the startup failure in the VS Code snap environment described. Done means the runtime starts there without SIGABRT and the Copilot agent host connects.

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

Descrição

Summary

The Linux x64 prebuild shipped as @github/[email protected] (inside VS Code Insiders 1.146.0-insider, classic snap revision 2623) aborts at startup on Linux:

OpenSSL initialization failed: cannot load libcrypto.so.3:
/snap/core20/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found
(required by /usr/lib/x86_64-linux-gnu/libcrypto.so.3); refusing to select an older OpenSSL

The process then dies with SIGABRT (~6 s after launch, on every launch).

This is a regression in the prebuild: the previous runtime.node shipped in VS Code Insiders revision 2621 (1.145.0-insider) does not reference libcrypto.so.3 at all and starts fine in the exact same environment. Related in spirit to #1805 (hard-coded native-tls/OpenSSL), but here the problem is that the Node runtime inside runtime.node is now built against shared OpenSSL and picks up the host libcrypto.so.3, while the binary's own DT_RPATH pins an old glibc.

Environment

  • Ubuntu 26.04.1 LTS, kernel 7.0.0-42-generic, glibc 2.43, snapd 2.78
  • @github/[email protected] (new prebuild, broken)
  • Previous prebuild in VS Code Insiders rev 2621 (works)
  • VS Code stable 1.144.1 prebuild (works)

Evidence

readelf/ldd on the bundled launcher (prebuilds/linux-x64/copilot-runtime):

0x000000000000000f (RPATH)  Library rpath: [/snap/core20/current/lib/x86_64-linux-gnu]
libc.so.6 => /snap/core20/current/lib/x86_64-linux-gnu/libc.so.6   # glibc 2.31

The same DT_RPATH is on runtime.node. Comparison of the three prebuilds of runtime.node:

build size sha256 (first 12) references to libcrypto.so.3
1.0.x shipped in VS Code Insiders rev 2621 146,604,848 f6d472122826 0
1.0.29-preview.1 (rev 2623) 147,403,200 e30087ebc123 2
VS Code stable rev 275 146,604,848 3504b2a250df 0

So the new runtime.node dlopens the host's libcrypto.so.3 (which requires GLIBC_2.38) while the process runs against core20's glibc 2.31 (imposed by the RPATH), and Node aborts instead of falling back.

Impact

In VS Code Insiders the Copilot agent host never connects, so every session operation fails:

Provider copilotcli is not ready to open ahp-session:/<uuid>; it may still be starting, so try again shortly
Request 'resolveSessionConfig' failed Client is not connected. Call start() first.

coredumpctl records one copilot-runtime SIGABRT per launch (13 in a single morning).

Expected

The runtime starts normally, as the 1.0.x prebuild does under the same RPATH.

Suggested fix

  • Bundle OpenSSL 3 with the prebuild (or build runtime.node against static OpenSSL), or
  • avoid the hard-coded /snap/core20/... RPATH in the prebuild so a compatible libc/libcrypto pair is selected, or
  • make the OpenSSL selection tolerate an incompatible host libcrypto.so.3 instead of aborting.

Workaround

Users can downgrade the VS Code snap (sudo snap revert code-insiders) and hold the refresh. Happy to test a candidate prebuild.

Linguagem predominante
Java
Estrelas
10.7k
Forks
1.5k
Métricas de merge de PRs
Nenhum PR com merge em 30d

Preparar o ambiente

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 github/copilot-sdk

Todas as issues de github/copilot-sdk

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

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