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)

未關閉
  • 哪裡不對？
#2,897 2 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
github, linux, node.js
領域
backend, devops

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
Java
星號
10.7k
分支
1.5k
30 天內沒有已合併 PR

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

github/copilot-sdk 的其他 Issue

查看 github/copilot-sdk 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。