What does this PR do?

Adds a fiber-local re-entrancy guard to method probes and integration tests exercising it.

When a probe targets a stdlib method that DI calls internally during snapshot building (e.g., String#length via SecureRandom.uuid), the probe would re-enter DI processing recursively. The guard prevents this by skipping DI processing for calls that occur while DI is already processing a probe.

The guard is a split guard: held during DI pre-processing (serialization) and post-processing (notification), but released during super() so that recursive calls and nested probes fire normally during user code execution.

Motivation:

Without this, a non-capture probe on String#length causes SystemStackError via: probe fires → build_snapshot → SecureRandom.uuid → gen_random_urandom → String#length → probe fires → ...

Change log entry

Yes. Dynamic Instrumentation: fix SystemStackError when probes target standard library methods used internally by probe processing.

Architecture:

The guard storage is fiber-local. Reads and writes go through seven new C-implemented module methods on Datadog::DI:

• in_probe? / enter_probe / leave_probe — guard state, backed by rb_thread_local_aref / rb_thread_local_aset (the same hashtable that backs Thread#[] / Thread#[]=, but bypassing Ruby method dispatch — so a user probe on Thread#[] or Thread#[]= cannot intercept guard reads/writes).
• invoke_proc — invokes a Proc via rb_proc_call_with_block, bypassing Proc#call dispatch. The wrapper invokes the do_super trampoline through this so a user probe on Proc#call cannot intercept it.
• array_empty? (RARRAY_LEN) / hash? (RB_TYPE_P) — used by the Ruby < 3 argument-splitting path (kwargs_from_splat) to test args shape and detect a trailing hash without dispatching Array#empty? / Kernel#is_a? (which would self-recurse if a user probe targets either). hash_empty? (RHASH_SIZE) is a symmetric counterpart that is not currently called by the wrapper.

The method probe wrapper body lives in Instrumenter#run_method_probe, an instance method that is lexically public (so the prepended wrapper can call it without .send, which a user probe on Object#send could otherwise intercept). The define_method block defines a do_super lambda that captures super's lexical binding: on Ruby 3+ it forwards super(*a, **k, &blk), on Ruby < 3 it replays the original ruby2_keywords-flagged splat via super(*args, &blk). run_method_probe invokes the original method via DI.invoke_proc(do_super, args, kwargs, target_block) instead of super directly — preserving super's prepended-class semantics while keeping the wrapper body at normal indentation in a regular method.

Line probes are not affected because Ruby's TracePoint is self-disabling during its callback.

Additional Notes:

Customer-observable contract: probes on stdlib methods called by DI internally are safe; nested invocations during DI processing don't fire the probe and don't count toward the rate limit.

How to test the change?

Automated:

bundle exec rspec spec/datadog/di/instrumenter_spec.rb spec/datadog/di/integration/instrumentation_spec.rb spec/datadog/di/integration/stdlib_probe_spec.rb spec/datadog/di/ext/in_probe_spec.rb

159 examples, 0 failures, 8 pending (unrelated pre-existing).

Test skips added in this PR:

• spec/datadog/di/integration/stdlib_probe_spec.rb — "does not self-recurse during do_super construction in another probed method":
  • Skipped on Ruby < 3.0 (skip "..." if Datadog::RubyVersion.is?("< 3.0")). On Ruby 2.7, prepending a lambda method onto Kernel does not intercept lambda { ... } calls — the wrapper is never entered, so the recursion bug being tested is unreachable. Platform limitation skip.
  • Skipped on Ruby >= 3.3 (skip "..." if Datadog::RubyVersion.is?(">= 3.3")). On Ruby 3.3+, the original Kernel#lambda raises ArgumentError when invoked via super(&blk) with a non-literal block — which is what the wrapper's do_super does. Probing Kernel#lambda on Ruby 3.3+ is therefore broken at a language layer below this PR's scope. This is a known customer-visible limitation; rejecting Kernel#lambda probes outright is handled in the companion PR DI: reject method probes on Kernel#lambda #5954.
  • CI proof: the test runs (and is correctly skipped on the listed versions) in Ruby X.Y / build & test (standard) [di:di_with_ext slot] jobs across the full supported Ruby range (2.5–4.0).

Known limitation (customer-facing): On Ruby 3.3+, method probes on Kernel#lambda may raise ArgumentError when the probed call site passes a non-literal block. This is a Ruby language behavior the tracer cannot work around; the companion PR #5954 rejects Kernel#lambda probes at hook time and surfaces an ERROR status to the customer.

Gobo (manual verification via Live Debugger UI):

1. Deploy gobo with a dd-trace-rb that includes this PR's branch
2. In the Datadog Live Debugger UI, set a method probe on String class, length method — this is the C-implemented stdlib method that triggered the SystemStackError
3. Set the probe to non-capture (log probe without snapshot) — this is the configuration that caused the crash due to the 5000/sec rate limit allowing recursive invocations
4. Hit any gobo endpoint (e.g., the home page) — String#length is called pervasively by Ruby code
5. Expected with this PR: a snapshot appears in the Live Debugger UI; gobo responds normally
6. Expected without this PR: gobo crashes with SystemStackError: stack level too deep

Actual results: without PR: in production env the server is surviving but printing SystemStackError in the log. Memory consumption grows without bounds (stopped server at 5 GB RSS in each worker). In development env the server becomes DOSed and shows a huge stack trace with the SystemStackError on top.

With PR: no errors in the log. Memory usage stable at 250 MB per worker.

Performance impact

This PR adds approximately 3 μs of overhead per probed method call.

The PR adds a re-entrancy guard to the method-probe wrapper: set a thread-local flag on entry, check it on every call, clear it on exit. This prevents DI from recursing into itself when it calls stdlib methods that customers have probed.

Costs (measured with benchmarks/di_instrument.rb against master at f9044e8cea, PR at 83ede0ecd5, pinned to a single Intel Core Ultra 7 165U E-core at 1.2 GHz via taskset -c 4, Ruby 3.2.3, one run per branch):

• Method-probe skip path: 5.6 → 9.0 μs/call (+3.4 μs, +60%). This is the path almost every probed call takes in production.
• Method-probe firing path: 27 → 28 μs/call (+1.4 μs, +5%). Smaller because the PR also defers caller_locations capture and moves Proc#call to C, partially offsetting the guard cost.
• Line probes and uninstrumented methods: unchanged.

The +3.4 μs is well outside the run's ±5% baseline noise. The +1.4 μs is close to it.

Why the firing-path regression (+1.4 μs) is smaller than the skip-path regression (+3.4 μs)

The two paths share the wrapper entry but diverge at the rate-limit check.

Skip path (rate limit rejects):

1. Enter wrapper
2. (new in PR) Set re-entrancy flag → check probe list → clear flag
3. Check rate limit → rejected
4. super to original method
5. Return

The PR adds the guard set/check/clear; almost nothing else changed on this path. The wrapper body was already small (~5.6 μs), so the guard's added cost dominates and the delta is ~+3.4 μs.

Firing path (rate limit accepts):

1. Enter wrapper
2. (new in PR) Set re-entrancy flag
3. Check rate limit → accepted
4. Build Context, capture caller, serialize args, dispatch to responder (this is most of the 27 μs)
5. (new in PR) Clear re-entrancy flag
6. super to original method
7. Return

The PR adds the guard here too — but the PR also changes this path:

• caller_locations capture is deferred into a depth-3 lambda thunk and only invoked when the responder asks for it (commit f292d07951)
• Proc#call dispatch moved to C to bypass user probes on Proc#call (commit c08dac2768)
• .send eliminated from the hot path (commit ce69d653d7)
• Array#empty? / Hash#empty? calls replaced with C-level RARRAY_LEN / RHASH_SIZE reads (commit 7040a5a2b6)

These optimizations only have surface area on the firing path (the skip path doesn't capture callers, doesn't dispatch to responders, doesn't run the argument-shape branches). So the firing path pays the guard cost (+~3 μs) and reclaims some of it from the optimizations (-~1.6 μs), netting +1.4 μs. The skip path pays the guard cost with nothing to reclaim.

The +1.4 μs delta is close to the ±5% in-run baseline noise, so the true firing-path overhead could be anywhere from roughly 0 to +3 μs — a second run would tighten it. The skip-path delta is large enough that noise can't account for it.