Issue #8886 has been reported by deivid (David Rodríguez).

----------------------------------------
Bug #8886: TracePoint API inconsistence when raise used
https://bugs.ruby-lang.org/issues/8886

Author: deivid (David Rodríguez)
Status: Open
Priority: Normal
Assignee: ko1 (Koichi Sasada)
Category: 
Target version: 
ruby -v: ruby 2.0.0p247 (2013-06-27 revision 41674) [i686-linux]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


=begin
When `raise` command is used, the TracePoint API triggers the following events in the following order

    1. RUBY_EVENT_C_CALL to the `raise` method
    2. RUBY_EVENT_RAISE
    3. RUBY_EVENT_C_RETURN

But what ruby actually does is

    1. Push frame into the stack when calling the `raise` c method.
    2. Pop frame from the stack
    3. And after popping the frame, raise the exception.

As you can see, 2 and 3 are reversed and this messes up byebug and (I guess) other users of the API.

To illustrate I use a similar program as I used in (invalid) #8538

    tp = TracePoint.trace do |tp|
      warn "%-8s %-11p" % [tp.event, tp.method_id]
    end
    raise "bang"

Actual output
    
    c_return :trace     
    line     nil        
    c_call   :raise     
    c_call   :new       
    c_call   :initialize
    c_return :initialize
    c_return :new       
    c_call   :backtrace 
    c_return :backtrace 
    raise    nil        
    c_return :raise     
    test_bug.rb:4:in `<main>': bang (RuntimeError)

Expected output

    c_return :trace     
    line     nil        
    c_call   :raise     
    c_call   :new       
    c_call   :initialize
    c_return :initialize
    c_return :new
    c_return :raise     
    c_call   :backtrace 
    c_return :backtrace 
    raise    nil        
    test_bug.rb:4:in `<main>': bang (RuntimeError)

I've made a patch that solves the issue and, as a result, the problems byebug is having. Please review and excuse me if I'm not being able to properly explain myself.

Thanks a lot!
=end


-- 
http://bugs.ruby-lang.org/