Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

JVM SIGSEGV crashes after upgrade from 1.61.1 to 1.62.0

Aperta
#11,373 3 commenti 13 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
java

Direzione di ricerca

Inizia esaminando il logs.txt allegato e gli entry point del crash indicati nel report, in particolare JavaProfiler.dump0, AgentTaskScheduler, DefaultConfigurationPoller e il percorso shaded di okhttp. Confronta le modifiche tra 1.61.1 e 1.62.0, quindi riproduci il problema su Java 25; il lavoro è completato quando la regressione è stata identificata e si è confermato che la JVM non va più in crash.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Java
Stelle
737
Fork
362
Merge medio
3g 18h
PR unite (30g)
180

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DataDog/dd-trace-java

Tutte le issue di DataDog/dd-trace-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.