[BUG]: SIGSEGV: Process terminated with SEGV_MAPERR (SIGSEGV)

[liveh2o]

Tracer Version(s)

2.40.0

Ruby Version(s)

ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [aarch64-linux]

Relevent Library and Version(s)

resque 3.0.0

Bug Report

The Resque child process was killed (seemingly) due to a null pointer exception after a period of time with experimental heap profiling enabled (DD_PROFILING_EXPERIMENTAL_HEAP_ENABLED). Disabling it resolved the issue.

The issue began after upgrading from 2.39.0 to 2.40.0.

Reproduction Code

No response

Configuration Block

Datadog.configure do |c|
  c.tracing.enabled = Tracing.enabled?
  c.tracing.instrument :aws, service_name: 'arc-api-aws'
  c.tracing.instrument :faraday, service_name: 'arc-api-faraday'
  c.tracing.instrument :http, service_name: 'arc-api-http'
  c.tracing.instrument :rails, service_name: 'arc-api'
  c.tracing.instrument :active_support, cache_service: 'arc-api-active_support-cache'
  c.tracing.instrument :active_job, service_name: 'arc-api-active_job'
  c.tracing.instrument :pg, service_name: 'arc-api-postgres', comment_propagation: 'full'
  c.tracing.instrument :resque, service_name: 'arc-api-resque'
  c.tracing.instrument :rake, service_name: 'arc-api-rake'

  if ENV['DD_TRACE_PARTIAL_FLUSH_ENABLED'] == 'true'
    c.tracing.partial_flush.enabled = true
    c.tracing.partial_flush.min_spans_threshold =
      Integer(ENV.fetch('DD_TRACE_PARTIAL_FLUSH_MIN_SPANS', 500))
  end

  c.appsec.enabled = Tracing.appsec_enabled?
  c.appsec.instrument :rails

  c.env = env
  c.version = Api::Application::VERSION
end

Error Logs

SIGSEGV (SEGV_MAPERR) at address 0x0000000000000000. Address is below the null-page threshold (0x0000000000001000), suggesting a direct null dereference on a null pointer. Crash in /usr/local/bundle/ruby/3.4.0/gems/datadog-2.40.0/lib/datadog_profiling_native_extension.3.4.9_x86_64-linux.so.

Stack Trace

0x7f653b3c988b ddtrace_rb_profile_frames (/usr/local/bundle/ruby/3.4.0/gems/datadog-2.40.0/ext/datadog_profiling_native_extension/private_vm_api_access.c:528)
0x7f653b3be606 prepare_sample_thread (/usr/local/bundle/ruby/3.4.0/gems/datadog-2.40.0/ext/datadog_profiling_native_extension/collectors_stack.c:636)
0x7f653b3b84a5 handle_sampling_signal (/usr/local/bundle/ruby/3.4.0/gems/datadog-2.40.0/ext/datadog_profiling_native_extension/collectors_cpu_and_wall_time_worker.c:686)
0x7f65685db050
0x7f6568df0000 rb_yjit_invalidate_ep_is_bp (/usr/src/ruby/yjit/src/cruby.rs:652)
0x7f6568c6a7b1 vm_make_env_each (/usr/src/ruby/vm.c:1040)
0x7f6568c6a702 vm_make_env_each (/usr/src/ruby/vm.c:969)
0x7f6568c6a529 rb_vm_make_proc_lambda (/usr/src/ruby/vm.c:1429)
0x7f6568c1c2a7 thread_initialize (/usr/src/ruby/thread.c:983)
0x7f6568c7fda1 vm_call0_body (/usr/src/ruby/vm_eval.c:229)
0x7f6568c80b89 vm_call0_cc (/usr/src/ruby/vm_eval.c:102)
0x7f6568c83944 rb_call0 (/usr/src/ruby/vm_eval.c:554)
0x7f6568c84422 rb_funcallv_kw (/usr/src/ruby/vm_eval.c:1070)
0x7f6568c18dd0 thread_s_new (/usr/src/ruby/thread.c:917)
0x7f6568c5eda5 vm_call_cfunc_with_frame_ (/usr/src/ruby/vm_insnhelper.c:3794)
0x7f6568c66c4f vm_sendish (/usr/src/ruby/vm_insnhelper.c:5972)
0x7f6568c749d9 vm_exec_core (/usr/src/ruby/insns.def:851)
0x7f6568c7a6f9 rb_vm_exec (/usr/src/ruby/vm.c:2595)
0x7f65215350c3

Operating System

Linux 8cf0d110d9dd 6.8.0-117-generic #117-Ubuntu SMP PREEMPT_DYNAMIC Thu May 7 17:26:37 UTC 2026 aarch64 GNU/Linux

How does Datadog help you?

No response

[ivoanjo]

Hey @liveh2o thanks for reaching out and sorry you ran into this issue!

Looking at it, this very much sounds like #6173 which we fixed in 2.41 -- you can see almost the same stack as you shared in our discussion in #6173 (comment) .

If possible, would you mind trying again with the latest version of the gem? 🙏

[liveh2o]

Hey @ivoanjo no worries. We have upgraded to 2.41.0 and observed the same symptoms (i.e., the child process died and had to be manually restarted), but unfortunately we didn't capture any error information this time. Once we're properly reporting exceptions, I can try again and see if the issue is resolved.

The original report was labeled as a crash by Datadog if that helps:

[ivoanjo]

Interesting... I wonder if perhaps we're seeing two issues, not one.

In the report above, you mentioned that:

• The issue showed up when upgrading from 2.39.0 to 2.40.0
• Disabling heap profiler also made the issue go away

I was re-checking the diff between 2.39.0 and 2.40.0 and I don't see any direct changes to the heap profiler there (although we did change some code that also gets used by the heap profiler).

Furthermore, we've recently landed #6176 which redoes how the heap profiler works, as we were seeing issues in Ruby 4 (although your report mentions 3.4).

1. Once 2.42.0 is out, do you mind giving it a try again?

2. Also, do you happen to know how long you ran 2.39.0 with heap profiling?

   I'm wondering if it really was a regression on 2.39.0, or if somehow the issue was latent there and perhaps didn't happen as often or something similar.