--001636ed69a80a74810482187800
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the information. Sorry for the confusion I caused by describing
the wrong behavior and giving a program that promoted that confusion.

Yes, JRuby does what is most  helpful and what I would expect it to do:
raise an error and continue tracing events. Ruby 1.9's behavior looks to me
like a bug, because after raising the error it gets itself in a state that
prevents further tracing from occurring (except by extraordinary measures
like reinstalling the trace hook).

I think I know how to fix this in Ruby 1.9, and I will post a bug report and
patch to redmine.

Ruby Specification folks: is there any behavior specified right for what
happens when a trace hook raises an error?

Are trace hooks considered part of Ruby or not?

On Thu, Mar 18, 2010 at 2:37 PM, Charles Oliver Nutter
<headius / headius.com>wrote:

> 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
>
>

--001636ed69a80a74810482187800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the information. Sorry for the confusion I caused by describing the wrong behavior and giving a program that promoted that confusion.<br><br>Yes, JRuby does what is most helpful and what I would expect it to do: raise an error and continue tracing events. Ruby 1.9&#39;s behavior looks to me like a bug, because after raising the error it gets itself in a state that prevents further tracing from occurring (except by extraordinary measures like reinstalling the trace hook).<br>
<br>I think I know how to fix this in Ruby 1.9, and I will post a bug report and patch to redmine. <br><br>Ruby Specification folks: is there any behavior specified right for what happens when a trace hook raises an error? <br>
<br>Are trace hooks considered part of Ruby or not? <br><br><div class="gmail_quote">On Thu, Mar 18, 2010 at 2:37 PM, Charles Oliver Nutter <span dir="ltr">&lt;headius / headius.com&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Mar 18, 2010 at 5:52 AM, Rocky Bernstein &lt;rockyb / rubyforge.org&gt; wrote:<br>

&gt; The &quot;sort of&quot; part is that in Ruby 1.9 the implementation of tracing sets a<br>
&gt; bit in the thread structure which turns off tracing into the tracer (or<br>
&gt; debugging into the debugger). When an exception that passes from hook to<br>
&gt; non-hook occurs, this bit doesn&#39;t get cleared.<br>
<br>
</div>That doesn&#39;t appear to be the case in JRuby. The bit clearing happens<br>
in a Java &quot;finally&quot; block, which runs no matter what happens in the<br>
hook itself. See below.<br>
<div class="im"><br>
&gt; Changing the program that was originally posted will show this better:<br>
&gt;<br>
&gt; s = Proc.new {<br>
&gt;  |event, file, lineno, mid, binding, klass|<br>
&gt;  puts &quot;#{event} #{mid} #{lineno}&quot;<br>
&gt;  unless $x<br>
&gt;  $x = true<br>
&gt;  raise RuntimeError<br>
&gt;  end<br>
&gt; }<br>
&gt; begin<br>
&gt;  set_trace_func(s)<br>
&gt;  puts &quot;after trace func&quot;<br>
&gt; rescue<br>
&gt;  puts &quot;Rescued&quot;<br>
&gt; end<br>
&gt; puts &quot;After begin&quot;<br>
&gt;<br>
&gt; Run this in Ruby 1.9 and perhaps it is more apparent that the program<br>
&gt; continues to the end. In the original posting if you look carefully you&#39;ll<br>
&gt; see that the rescue did run *after* the trace hook issued a raise inside the<br>
&gt; begin block. It is the *second* raise issued in the hook function that<br>
&gt; terminates the program because the debugged program is no longer in a<br>
&gt; rescue&#39;d block.<br>
<br>
</div>In the JRuby case, for your original script, it seemed to take several<br>
raises for it to terminate. All the trace events appeared to be in the<br>
main body of code, and not inside the trace hook.<br>
<br>
Here&#39;s the behavior for the new script in JRuby, which seems to<br>
continue tracing appropriately after the initial raise inside the hook<br>
<br>
~/projects/jruby  jruby --debug hook_thing2.rb<br>
line 11 (first event, causes raise)<br>
c-call === 11 (rescue calling ===)<br>
c-return === 11 (=== returning)<br>
line 13 (inside rescue block)<br>
c-call puts 13 (calling puts)<br>
c-call write 13 (puts calls write)<br>
Rescuedc-return write 13 (write returns)<br>
c-call write 13 (puts calls write again for \n)<br>
<br>
c-return write 13 (write returns)<br>
c-return puts 13 (puts returns)<br>
line 15 (outside rescue block)<br>
c-call puts 15 (calling puts)<br>
c-call write 15 (puts calls write)<br>
After beginc-return write 15 (write returns)<br>
c-call write 15 (puts calls write for \n)<br>
<br>
c-return write 15 (write returns)<br>
c-return puts 15 (puts returns)<br>
<br>
Is this the output you expected? If not, what do you expect?<br>
<div class="im"><br>
&gt; From what you describe from JRuby, it sounds like it has a similar behavior<br>
&gt; possibly because it is implemented underneath in a similar way. So<br>
&gt; rationalizing this as &quot;this makes sense because this happened in between<br>
&gt; statements and not in the program&quot; I don&#39;t think is accurately capturing<br>
&gt; what&#39;s going inside either interpreter.<br>
<br>
</div>Your original script could never do anything but terminate because the<br>
hooks just kept re-throwing...or at least they did in JRuby, which<br>
turns tracing back on when the hook is exited, even if it&#39;s exited<br>
abnormally (because of an exception).<br>
<br>
- Charlie<br>
<br>
</blockquote></div><br>

--001636ed69a80a74810482187800--