Ruby 2.5 introduced a change [0] that removed trace instructions from Ruby VM, this also lead to the dtrace probes of `ruby:::method-entry` and `ruby:::method-return` not firing by default. The TracePoint has to be enabled before the expected code block like so: `TracePoint.new{}.enable`.

These 2 probes are responsible for catching method call and return for Ruby-only methods. The `ruby:::cmethod*` probes are unaffected and are firing by default without needing to call anything extra as expected.

This is easily reproducible with Ruby 3.3 and Integer#times. To test with earlier rubies, other ruby-level method has to be found. Ruby 3.3 is easier to test this with because Integer#times was promoted to Ruby from C level [1], which exposed this problem.

Ruby 3.2 can use Integer#succ in place of Integer#times call.

[0] https://bugs.ruby-lang.org/issues/14104
[1] https://github.com/ruby/ruby/pull/8388

Reproducible: Always

Steps to Reproduce:
As root:
1. dnf install ruby ruby-doc ruby-libs systemtap
2. stap-prep
3. stap -s 100 -v /usr/share/doc/ruby-doc/ruby-exercise.stp  >ruby.log &
4. sleep 120 # wait for systemtap to be ready
5. ruby --disable-gems -e "5.times { printf \"Ruby!\n\" }'"

See ruby.log for results.

I verified reproduction works with at most Fedora 39, Fedora Rawhide fails on systemtap compilation at the moment.
Actual Results:  
Integer::times does not appear in logs.

Expected Results:  
`Integer::times` appears in log exactly twice. Once for entry and once on return. `Integer#succ` appears in between the `Integer::times` entry and return.

Workaround is to use TracePoint before code we want probes to fire for.
Like this: `ruby --disable-gems -e "TracePoint.new{}.enable; 5.times { printf \"Ruby!\n\" }'"`
This achieves expected results, but ideally should not be needed.

A patch was proposed:
~~~
diff --git a/vm_insnhelper.c b/vm_insnhelper.c
index 9f9d0fcfd8..ee0a77e9fb 100644
--- a/vm_insnhelper.c
+++ b/vm_insnhelper.c
@@ -6489,7 +6489,6 @@ vm_trace_hook(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp, const VAL
     if (event & global_hooks->events) {
         /* increment PC because source line is calculated with PC-1 */
         reg_cfp->pc++;
-        vm_dtrace(event, ec);
         rb_exec_event_hook_orig(ec, global_hooks, event, self, 0, 0, 0 , val, 0);
         reg_cfp->pc--;
     }
@@ -6622,6 +6621,8 @@ vm_trace(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp)
                 vm_trace_hook(ec, reg_cfp, pc, RUBY_EVENT_RETURN, RUBY_EVENT_RETURN, global_hooks, bmethod_local_hooks_ptr, TOPN(0));
             }
 
+            vm_dtrace(pc_events & RUBY_EVENT_CALL, ec);
+
             // Pin the iseq since `local_hooks_ptr` points inside the iseq's slot on the GC heap.
             // We need the pointer to stay valid in case compaction happens in a trace hook.
             //
~~~
It does not seem to help.

I have 2 set of snippets to further illustrate the issue. One is using the tracepoint workaround, the other is executed without it. If there is "default" in filename it is Ruby without the patch, and if there is "patched" in the filename, the Ruby used has the patch applied.

Without using tracepoint, executed as as in reproducer: https://gitlab.com/-/snippets/3625897
With tracepoint, Ruby command is like in the workaround: https://gitlab.com/-/snippets/3625366