Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

TLS memory overflow - V8 garbage collection

オープン
#65,263 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript, nodejs

調査の方向性

issue に記載されている暗号化された WebSocket Performance Test の設定と npm run server を使って、aphorio リポジトリで再現する。V8 のガベージコレクションとヒープエラーの出力を確認しながら、TLS 実行と暗号化されていない実行を比較する。暗号化されたテストがメモリを使い果たすことなく完了し、結果を返せば完了とする。

索引モデルが issue の本文から書いたものです。

説明

tls
Version

26.7.0

Platform
Microsoft Windows NT 10.0.26200.0 x64
Subsystem

No response

What steps will reproduce the bug?
  1. git clone https://github.com/prettydiff/aphorio
  2. npm run server
  3. Open a web browser to localhost and the specified port number
  4. In the browser use the left side navigation and choose Performance Test
  5. Choose these experiment settings:
    • WebSocket
    • Encrypted
    • Send Only
    • Force GC Between Tests
    • Location - 127.0.0.1
    • Port - specified secure port
    • Test Quantity - 5000000
    • Number of tests - 10
    • Message Body - "test"
How often does it reproduce? Is there a required condition?

50%, no required condition

What is the expected behavior? Why is that the expected behavior?

The expected behavior is the application remains executing and returns test results.

What do you see instead?
<--- Last few GCs --->

[16960:00000220C3725000]   178739 ms: Scavenge (during sweeping) 7914.8 (7952.1) -> 7887.9 (7954.4) MB, pooled: 0.0 MB, 3.29 / 0.00 ms (average mu = 0.348, current mu = 0.370) allocation failure;
[16960:00000220C3725000]   179468 ms: Incremental Mark-Compact (reduce) 7919.9 (7957.1) -> 7890.5 (7896.4) MB, pooled: 0.0 MB, 33.63 / 0.00 ms (+ 668.4 ms in 133 steps since start of marking, biggest step 5.2 ms, walltime since start of marking 720 ms) (a
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF748A7641D node::OnFatalError+1325
 2: 00007FF749840FB1 v8::Function::NewInstance+577
 3: 00007FF749625287 SSL_CTX_set_stateless_cookie_verify_cb+504087
 4: 00007FF749622E4D SSL_CTX_set_stateless_cookie_verify_cb+494813
 5: 00007FF74961D511 SSL_CTX_set_stateless_cookie_verify_cb+471969
 6: 00007FF749624DEA SSL_CTX_set_stateless_cookie_verify_cb+502906
 7: 00007FF7493C8C8F v8::MemorySpan<v8::internal::DirectHandle<v8::internal::Map> >::operator[]+890943
 8: 00007FF749665ADE v8::internal::StrongRootAllocatorBase::deallocate_impl+201886
 9: 00007FF74986B73C v8::ArrayBuffer::New+172
10: 00007FF748AD2A7F node::Buffer::New+43359
11: 00000220EBD501DA
Additional information

Unencrypted tests never fail in this manner as they will run to completion as long as it takes. This problem is specific to TLS. I have been able to run experiments comprising greater than 50,000,000 WebSocket messages repeatedly without any failures.

The error messaging indicates garbage collection in V8 is the culprit, but I suspect the problem could be OpenSSL causing V8 to hang unexpectedly until all memory is consumed.

This is an aside, but it seems at maximum efficiency I can send 3,250,000 messages in 0.002 seconds but the next 0.998 seconds is spent on garbage collection. I don't know if this is a potentially untapped optimization target. Aside from the garbage collection time it seems executing WebSockets like this application does is about 2300x faster than Bun.
I had a defect in my profiler.

主要言語
JavaScript
スター
122k
フォーク
37.4k
平均マージ
4日 4時間
マージ済み PR(30日)
276

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

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

nodejs/node のほかの issue

nodejs/node の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

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

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