JVM SIGSEGV crashes after upgrade from 1.61.1 to 1.62.0

Bắt đầu bằng cách xem xét logs.txt đính kèm và các điểm vào crash được nêu trong báo cáo, đặc biệt là JavaProfiler.dump0, AgentTaskScheduler, DefaultConfigurationPoller và đường dẫn shaded okhttp. So sánh các thay đổi giữa 1.61.1 và 1.62.0, sau đó tái hiện lỗi trên Java 25; hoàn tất nghĩa là đã xác định được hồi quy và xác nhận rằng JVM không còn bị crash.

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