Issue Description
We're experiencing recurring segmentation faults in production on our Sidekiq background worker. The crash occurs inside Ruby's <internal:trace_point> implementation, called from sentry-ruby's include_local_variables TracePoint handler.
Crash Dump
<internal:trace_point>:382: [BUG] Segmentation fault at 0x00000001c63e5400
ruby 3.4.6 (2025-09-16 revision dbd83256b1) +YJIT +PRISM [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0109 p:0003 s:0725 e:000724 METHOD <internal:trace_point>:382
c:0108 p:0021 s:0721 e:000720 BLOCK sentry-ruby-5.27.0/lib/sentry-ruby.rb:74 [FINISH]
c:0107 p:0197 s:0715 e:000714 BLOCK /usr/local/lib/ruby/3.4.0/resolv.rb:570
c:0106 p:0012 s:0703 e:000702 BLOCK /usr/local/lib/ruby/3.4.0/resolv.rb:1168 [FINISH]
c:0105 p:0027 s:0698 e:000697 METHOD <internal:array>:228
c:0104 p:0007 s:0692 e:000691 BLOCK /usr/local/lib/ruby/3.4.0/resolv.rb:1166
c:0103 p:0027 s:0688 e:000687 METHOD <internal:array>:228
c:0102 p:0006 s:0682 e:000681 BLOCK /usr/local/lib/ruby/3.4.0/resolv.rb:1165
c:0101 p:0027 s:0678 e:000677 METHOD <internal:array>:228
c:0100 p:0028 s:0672 e:000671 METHOD /usr/local/lib/ruby/3.4.0/resolv.rb:1163
c:0099 p:0030 s:0664 e:000663 METHOD /usr/local/lib/ruby/3.4.0/resolv.rb:540
c:0098 p:0008 s:0654 e:000653 METHOD /usr/local/lib/ruby/3.4.0/resolv.rb:523
c:0097 p:0022 s:0647 e:000646 METHOD /usr/local/lib/ruby/3.4.0/resolv.rb:414
SEGV received in SEGV handler
./entrypoint_worker.sh: line 29: 110 Aborted (core dumped) bundle exec sidekiq
What We Know
- The crash happens inside
<internal:trace_point>:382, called from sentry-ruby.rb:74 — the TracePoint handler registered by include_local_variables = true
resolv.rb (Ruby's DNS resolver) is in the call stack — it raises internal exceptions as part of normal flow control, which triggers the global TracePoint on :raise
- A double SEGV occurred (
SEGV received in SEGV handler), so the C-level backtrace was not printed
- Ruby GC heap metrics and memory usage showed no anomalies before the crash
- The Sidekiq process was running concurrent workloads
Reproduction Steps
Run concurrent jobs in the corresponding versions that might eventually raise exceptions
Environment
- sentry-ruby: 5.27.0
- Ruby: 3.4.6 (2025-09-16 revision dbd83256b1) +YJIT +PRISM [x86_64-linux]
- Sidekiq: background worker with ~25 concurrent threads
- Platform: Linux
Sentry Configuration
Sentry.init do |config|
config.include_local_variables = true
config.traces_sample_rate = 1.0
config.profiles_sample_rate = 1.0
end
Expected Behavior
Not to crash sidekiq server
Actual Behavior
Crashing server
Ruby Version
3.4.6 (2025-09-16 revision dbd83256b1)
SDK Version
5.27.0
Integration and Its Version
Sidekiq
Sentry Config
Sentry.init do |config|
config.include_local_variables = true
config.traces_sample_rate = 1.0
config.profiles_sample_rate = 1.0
end
Issue Description
We're experiencing recurring segmentation faults in production on our Sidekiq background worker. The crash occurs inside Ruby's
<internal:trace_point>implementation, called from sentry-ruby'sinclude_local_variablesTracePoint handler.Crash Dump
What We Know
<internal:trace_point>:382, called fromsentry-ruby.rb:74— the TracePoint handler registered byinclude_local_variables = trueresolv.rb(Ruby's DNS resolver) is in the call stack — it raises internal exceptions as part of normal flow control, which triggers the global TracePoint on:raiseSEGV received in SEGV handler), so the C-level backtrace was not printedReproduction Steps
Run concurrent jobs in the corresponding versions that might eventually raise exceptions
Environment
Sentry Configuration
Expected Behavior
Not to crash sidekiq server
Actual Behavior
Crashing server
Ruby Version
3.4.6 (2025-09-16 revision dbd83256b1)
SDK Version
5.27.0
Integration and Its Version
Sidekiq
Sentry Config