[#28561] Ruby::DL vs Ruby::FFI — Aston <blackapache512-ticket@...>

Ruby.DL and FFI libraries are great for programmers like me who are not internet programmers, but are more interested in scientific and number processing etc.

11 messages 2010/03/08

[#28686] trunk (26947) build fail with msys/mingw/vista — Jon <jon.forums@...>

I get the following build failure when msysgit's "c:\git\cmd" dir is on PATH.

8 messages 2010/03/16

[#28687] [Bug #2973] rb_bug - Segmentation fault - error.c:213 — rudolf gavlas <redmine@...>

Bug #2973: rb_bug - Segmentation fault - error.c:213

10 messages 2010/03/16

[#28735] [Bug #2982] Ruby tries to link with both openssl and readline — Lucas Nussbaum <redmine@...>

Bug #2982: Ruby tries to link with both openssl and readline

16 messages 2010/03/18

[#28736] [Bug #2983] Ruby (GPLv2 only) tries to link to with readline (now GPLv3) — Lucas Nussbaum <redmine@...>

Bug #2983: Ruby (GPLv2 only) tries to link to with readline (now GPLv3)

10 messages 2010/03/18

[#28907] [Bug #3000] Open SSL Segfaults — Christian Höltje <redmine@...>

Bug #3000: Open SSL Segfaults

19 messages 2010/03/23

[#28924] [Bug #3005] Ruby core dump - [BUG] rb_sys_fail() - errno == 0 — Sebastian YEPES <redmine@...>

Bug #3005: Ruby core dump - [BUG] rb_sys_fail() - errno == 0

10 messages 2010/03/24

[#28954] [Feature #3010] slow require gems in ruby 1.9.1 — Miao Jiang <redmine@...>

Feature #3010: slow require gems in ruby 1.9.1

15 messages 2010/03/24

[#29179] [Bug #3071] Convert rubygems and rdoc to use psych — Aaron Patterson <redmine@...>

Bug #3071: Convert rubygems and rdoc to use psych

10 messages 2010/03/31

[ruby-core:28763] Re: When a trace hook raises an exception, should it terminate the program?

From: Charles Oliver Nutter <headius@...>
Date: 2010-03-18 18:37:28 UTC
List: ruby-core #28763
On Thu, Mar 18, 2010 at 5:52 AM, Rocky Bernstein <rockyb@rubyforge.org> wrote:
> The "sort of" part is  that in Ruby 1.9 the implementation of tracing sets a
> bit in the thread structure which turns off tracing into the tracer (or
> debugging into the debugger). When an exception that passes from hook to
> non-hook occurs, this bit doesn't get cleared.

That doesn't appear to be the case in JRuby. The bit clearing happens
in a Java "finally" block, which runs no matter what happens in the
hook itself. See below.

> Changing the program that was originally posted will show this better:
>
> s = Proc.new {
>   |event, file, lineno, mid, binding, klass|
>   puts "#{event} #{mid} #{lineno}"
>   unless $x
>     $x = true
>     raise RuntimeError
>   end
> }
> begin
>   set_trace_func(s)
>   puts "after trace func"
> rescue
>   puts "Rescued"
> end
> puts "After begin"
>
> Run this in Ruby 1.9 and perhaps it is more apparent that the program
> continues to the end. In the original posting if you look carefully you'll
> see that the rescue did run *after* the trace hook issued a raise inside the
> begin block. It is the *second* raise issued in the hook function that
> terminates the program because the debugged program is no longer in a
> rescue'd block.

In the JRuby case, for your original script, it seemed to take several
raises for it to terminate. All the trace events appeared to be in the
main body of code, and not inside the trace hook.

Here's the behavior for the new script in JRuby, which seems to
continue tracing appropriately after the initial raise inside the hook

~/projects/jruby ➔ jruby --debug hook_thing2.rb
line  11 (first event, causes raise)
c-call === 11 (rescue calling ===)
c-return === 11 (=== returning)
line  13 (inside rescue block)
c-call puts 13 (calling puts)
c-call write 13 (puts calls write)
Rescuedc-return write 13 (write returns)
c-call write 13 (puts calls write again for \n)

c-return write 13 (write returns)
c-return puts 13 (puts returns)
line  15 (outside rescue block)
c-call puts 15 (calling puts)
c-call write 15 (puts calls write)
After beginc-return write 15 (write returns)
c-call write 15 (puts calls write for \n)

c-return write 15 (write returns)
c-return puts 15 (puts returns)

Is this the output you expected? If not, what do you expect?

> From what you describe from JRuby, it sounds like it has a similar behavior
> possibly because it is implemented underneath in a similar way. So
> rationalizing this as "this makes sense because this happened in between
> statements and not in the program" I don't think is accurately capturing
> what's going inside either interpreter.

Your original script could never do anything but terminate because the
hooks just kept re-throwing...or at least they did in JRuby, which
turns tracing back on when the hook is exited, even if it's exited
abnormally (because of an exception).

- Charlie

In This Thread