Return 0 if there is no CFP on the EC yet

[tenderlove]

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

[k0kubun]

For this to be safe, I thought ec->cfp must become non-zero only after its end_cfp (ec->vm_stack + ec->vm_stack_size) becomes non-zero. If we always use rb_ec_initialize_vm_stack to initialize those fields, because ec->cfp is set using end_cfp, ec->cfp is set afterwards and the assignment order is unlikely (maybe impossible) to be reversed. So I guess (or hope) that case will be safe with this patch.