Return 0 if there is no CFP on the EC yet StackProf uses a signal handler to call `rb_profile_frames`. Signals are delivered to threads randomly, and can be delivered after the thread has been created but before the CFP has been established on the EC. This commit returns early if there is no CFP to use. Here is some info from the core files we are seeing. Here you can see the CFP on the current EC is 0x0: ``` (gdb) p ruby_current_ec $20 = (struct rb_execution_context_struct *) 0x7f3481301b50 (gdb) p ruby_current_ec->cfp $21 = (rb_control_frame_t *) 0x0 ``` Here is where VM_FRAME_CFRAME_P gets a 0x0 CFP: ``` 6 VM_FRAME_CFRAME_P (cfp=0x0) at vm_core.h:1350 7 VM_FRAME_RUBYFRAME_P (cfp=<optimized out>) at vm_core.h:1350 8 rb_profile_frames (start=0, limit=2048, buff=0x7f3493809590, lines=0x7f349380d590) at vm_backtrace.c:1587 ``` Down the stack we can see this is happening after thread creation: ``` 19 0x00007f3495bf9420 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 20 0x000055d531574e55 in thread_start_func_2 (th=<optimized out>, stack_start=<optimized out>) at thread.c:676 21 0x000055d531575b31 in thread_start_func_1 (th_ptr=<optimized out>) at thread_pthread.c:1170 22 0x00007f3495bed609 in start_thread (arg=<optimized out>) at pthread_create.c:477 23 0x00007f3495b12133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ``` --- vm_backtrace.c | 9 +++++++++ 1 file changed, 9 insertions(+)
The following new debug context APIs are for implementing debugger's `next` (step over) and similar functionality. * `rb_debug_inspector_frame_depth(dc, index)` returns `index`-th frame's depth. * `rb_debug_inspector_current_depth()` returns current frame depth. The frame depth is not related to the frame index because debug context API skips some special frames but proposed `_depth()` APIs returns the count of all frames (raw depth).
* s/Innteger/Integer/ * s/diretory/directory/ * s/Bufer/Buffer/ * s/defalt/default/ * s/covearge/coverage/
This patch pushes dummy frames when loading code for the profiling purpose. The following methods push a dummy frame: * `Kernel#require` * `Kernel#load` * `RubyVM::InstructionSequence.compile_file` * `RubyVM::InstructionSequence.load_from_binary` https://bugs.ruby-lang.org/issues/18559
The `rb_profile_frames` API did not skip the two dummy frames that each thread has at its beginning. This was unlike `backtrace_each` and `rb_ec_parcial_backtrace_object`, which do skip them. This does not seem to be a problem for non-main thread frames, because both `VM_FRAME_RUBYFRAME_P(cfp)` and `rb_vm_frame_method_entry(cfp)` are NULL for them. BUT, on the main thread `VM_FRAME_RUBYFRAME_P(cfp)` was true and thus the dummy thread was still included in the output of `rb_profile_frames`. I've now made `rb_profile_frames` skip this extra frame (like `backtrace_each` and friends), as well as add a test that asserts the size and contents of `rb_profile_frames`. Fixes [Bug #18907] (<https://bugs.ruby-lang.org/issues/18907>)
[Misc #18891]
Use ISEQ_BODY macro to get the rb_iseq_constant_body of the ISeq. Using this macro will make it easier for us to change the allocation strategy of rb_iseq_constant_body when using Variable Width Allocation.