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

JVM SIGSEGV crashes after upgrade from 1.61.1 to 1.62.0

オープン
#11,373 コメント 3 件 リアクション 13 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
静か
技術スタック
java

調査の方向性

まず、添付された logs.txt と、レポートで示されているクラッシュのエントリーポイント、特に JavaProfiler.dump0、AgentTaskScheduler、DefaultConfigurationPoller、shaded okhttp パスを確認します。1.61.1 と 1.62.0 の変更を比較し、その後 Java 25 で再現します。回帰が特定され、JVM がクラッシュしなくなったことを確認できれば完了です。

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

説明

type: bug report
Tracer Version(s)

1.62.0

Java Version(s)

25

JVM Vendor

Eclipse Adoptium / Temurin

Bug Report

After upgrading dd-trace-java from 1.61.1 to 1.62.0, the JVM started crashing with SIGSEGV (and one UNKNOWN signal) on multiple tasks.
Reverting to 1.61.1 with no other changes made the crashes stop.

Crash tracking is enabled, and we have collected several distinct crash signatures. They cluster into three groups:

  1. SIGSEGV inside the Datadog profiler native dump path:
    Profiler::updateThreadName(jvmtiEnv*, JNIEnv, _jobject, bool)
    -> jvmti_Deallocate
    called from JavaProfiler.dump0 via the profiling system's periodic
    snapshot task (AgentTaskScheduler$PeriodicTask).

  2. SIGSEGV in JIT inline-cache / wrong-method handling:
    SharedRuntime::find_callee_info_helper
    -> handle_ic_miss_helper / handle_wrong_method
    Observed on multiple call sites, including:

    • the agent's own shaded okhttp during remote-config polling
      (datadog.okhttp3...Http1Codec$FixedLengthSink.close, called from
      DefaultConfigurationPoller.fetchConfiguration), seen repeatedly
    • a Micrometer StepMeterRegistry rollover scheduled task
      (io.micrometer.core.instrument.step.StepTuple2.rollCount)
  3. JVM-internal crashes around the code cache / GC:

    • nmethod::is_unloading -> DependencyContext::clean_unloading_dependents
      on a G1 code-cache unloading worker
    • G1CodeRootSet::add(nmethod*) -> nmethod::oops_do -> register_nmethod
      on a C1 CompileBroker thread installing a freshly compiled nmethod
      (crashed inside concurrentHashTable.inline.hpp:684)

All crashes occur either on a Datadog-managed thread or in code installed by the agent (its shaded okhttp). The stacks above come from dd-trace-java's own crashtracking output, which was enabled at the time.

hs_err_pid*.log files are not available: this is running on AWS ECS, and the crashing tasks were recycled before we could retrieve them.

Workaround: pinning back to 1.61.1 removes the crashes entirely.

logs.txt

Expected Behavior

Upgrading dd-trace-java from 1.61.1 to 1.62.0 should not cause JVM crashes.

Reproduction Code

No response

主要言語
Java
スター
736
フォーク
364
平均マージ
3日 13時間
マージ済み PR(30日)
213

環境構築

はじめの一歩

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

DataDog/dd-trace-java のほかの issue

DataDog/dd-trace-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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