JVM SIGSEGV crashes after upgrade from 1.61.1 to 1.62.0

Comienza revisando el logs.txt adjunto y los puntos de entrada del crash mencionados en el informe, especialmente JavaProfiler.dump0, AgentTaskScheduler, DefaultConfigurationPoller y la ruta shaded de okhttp. Compara los cambios entre 1.61.1 y 1.62.0 y, después, reproduce el problema en Java 25; se considera terminado cuando se haya identificado la regresión y confirmado que la JVM ya no se bloquea.

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