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 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
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 はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/copilot-sdk のほかの issue

github/copilot-sdk の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。