Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Compiler
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Once the server code for JRUBY-2307 jits, it starts spitting out this text, which would mean that a break jump is getting all the way out to a thread:

      [headius @ cnutter:~/projects/jruby]
      $ Exception in thread "Thread-62" org.jruby.exceptions.JumpException$BreakJump 
      jruby client.rb 
      Worked with size 1007
      Worked with size 1008
      [headius @ cnutter:~/projects/jruby]
      $ Exception in thread "Thread-63" org.jruby.exceptions.JumpException$BreakJump
      jruby client.rb 
      Worked with size 1007
      Worked with size 1008
      ...
      

      It did not appear to affect execution, but could mean there's some logging we need to remove. It also likely means break handling is broken somewhere in the compiler.

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        Moving to 1.3; no investigation done yet.

        Show
        Charles Oliver Nutter added a comment - Moving to 1.3; no investigation done yet.
        Hide
        Charles Oliver Nutter added a comment -

        No other reports of this in the wild, so bumping.

        Show
        Charles Oliver Nutter added a comment - No other reports of this in the wild, so bumping.
        Hide
        Wayne Walker added a comment -

        We are seeing this error too. It occurs in our adhearsion server under any significant load, apparently when spawning threads rapidly.

        Exception in thread "Thread-264" org.jruby.exceptions.JumpException$BreakJump

        Is there anything we can do to gather more information? Execution does appear to continue, but I'm not certain (found it investigating lots of dropped calls).

        Show
        Wayne Walker added a comment - We are seeing this error too. It occurs in our adhearsion server under any significant load, apparently when spawning threads rapidly. Exception in thread "Thread-264" org.jruby.exceptions.JumpException$BreakJump Is there anything we can do to gather more information? Execution does appear to continue, but I'm not certain (found it investigating lots of dropped calls).
        Hide
        Charles Oliver Nutter added a comment -

        Wayne: Is that all you're seeing? I'd be fine with escalating this if you're seeing it in the real world...but hopefully you have some additional information.

        I could also create a build with some debugging for you if you have a way to cause this to happen. Then we could gather more information about where it's happening.

        Show
        Charles Oliver Nutter added a comment - Wayne: Is that all you're seeing? I'd be fine with escalating this if you're seeing it in the real world...but hopefully you have some additional information. I could also create a build with some debugging for you if you have a way to cause this to happen. Then we could gather more information about where it's happening.
        Hide
        Rick Ohnemus added a comment -

        I'm starting to see this on a production server. Not sure what yet what was going on when it happened since only minimal logging was enabled in the applications.

        Show
        Rick Ohnemus added a comment - I'm starting to see this on a production server. Not sure what yet what was going on when it happened since only minimal logging was enabled in the applications.
        Hide
        Charles Oliver Nutter added a comment -

        Upping priority to Critical.

        Show
        Charles Oliver Nutter added a comment - Upping priority to Critical.
        Hide
        Ben Summers added a comment -

        I'm seeing this too with 1.3.1, in code which is evaled after being received over a DRb connection from MRI.

        Show
        Ben Summers added a comment - I'm seeing this too with 1.3.1, in code which is evaled after being received over a DRb connection from MRI.
        Hide
        Charles Oliver Nutter added a comment -

        Ok folks, my old way of reproducing this no longer reproduces it. I'm guessing this is because DRb was using timeout.rb before, which has now been implemented in a different way. I can reproduce this message, but only by doing something which is broken anyway: a bare 'break' inside a Thread.new { }. It should probably be a LocalJumpError, but the BreakJump bubbling out is not (in this case) indicative of anything useful.

        So I'm going to have to punt this until one of you can sort out a reproducible case. I have, in 1.4 (post RC) added a property that will cause BreakJump (and a few others) to show a complete backtrace, which you all could use on your servers to get more information back to us. It will slow down non-local flow control somewhat (e.g. return, break, next within a closure), so once you get some results back you'll want to switch it off again, but it should help us sort out specific places this is happening.

        Example, using my contrived break-in-Thread case:

        ~/projects/jruby ➔ jruby -e "Thread.new { break }.join"
        Exception in thread "Thread-1" org.jruby.exceptions.JumpException$BreakJump
        
        ~/projects/jruby ➔ jruby -J-Djruby.jump.backtrace=true -e "Thread.new { break }.join"
        Exception in thread "Thread-1" org.jruby.exceptions.JumpException$BreakJump
        	at org.jruby.exceptions.JumpException.originalFillInStackTrace(JumpException.java:103)
        	at org.jruby.exceptions.JumpException.fillInStackTrace(JumpException.java:96)
        	at java.lang.Throwable.<init>(Throwable.java:181)
        	at java.lang.Exception.<init>(Exception.java:29)
        	at java.lang.RuntimeException.<init>(RuntimeException.java:32)
        	at org.jruby.exceptions.JumpException.<init>(JumpException.java:75)
        	at org.jruby.exceptions.JumpException$FlowControlException.<init>(JumpException.java:51)
        	at org.jruby.exceptions.JumpException$BreakJump.<init>(JumpException.java:61)
        	at org.jruby.javasupport.util.RuntimeHelpers.breakJump(RuntimeHelpers.java:831)
        	at ruby.__dash_e__.block_0$RUBY$__block__(-e:1)
        	at ruby.__dash_e__BlockCallback$block_0$RUBY$__block__xx1.call(Unknown Source)
        	at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:125)
        	at org.jruby.runtime.BlockBody.call(BlockBody.java:72)
        	at org.jruby.runtime.BlockBody.call(BlockBody.java:78)
        	at org.jruby.runtime.Block.call(Block.java:89)
        	at org.jruby.RubyProc.call(RubyProc.java:221)
        	at org.jruby.RubyProc.call(RubyProc.java:204)
        	at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:94)
        	at java.lang.Thread.run(Thread.java:637)
        

        Marking 1.x+ and HelpWanted.

        Show
        Charles Oliver Nutter added a comment - Ok folks, my old way of reproducing this no longer reproduces it. I'm guessing this is because DRb was using timeout.rb before, which has now been implemented in a different way. I can reproduce this message, but only by doing something which is broken anyway: a bare 'break' inside a Thread.new { }. It should probably be a LocalJumpError, but the BreakJump bubbling out is not (in this case) indicative of anything useful. So I'm going to have to punt this until one of you can sort out a reproducible case. I have, in 1.4 (post RC) added a property that will cause BreakJump (and a few others) to show a complete backtrace, which you all could use on your servers to get more information back to us. It will slow down non-local flow control somewhat (e.g. return, break, next within a closure), so once you get some results back you'll want to switch it off again, but it should help us sort out specific places this is happening. Example, using my contrived break-in-Thread case: ~/projects/jruby &#10132; jruby -e "Thread.new { break }.join" Exception in thread "Thread-1" org.jruby.exceptions.JumpException$BreakJump ~/projects/jruby &#10132; jruby -J-Djruby.jump.backtrace=true -e "Thread.new { break }.join" Exception in thread "Thread-1" org.jruby.exceptions.JumpException$BreakJump at org.jruby.exceptions.JumpException.originalFillInStackTrace(JumpException.java:103) at org.jruby.exceptions.JumpException.fillInStackTrace(JumpException.java:96) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.jruby.exceptions.JumpException.<init>(JumpException.java:75) at org.jruby.exceptions.JumpException$FlowControlException.<init>(JumpException.java:51) at org.jruby.exceptions.JumpException$BreakJump.<init>(JumpException.java:61) at org.jruby.javasupport.util.RuntimeHelpers.breakJump(RuntimeHelpers.java:831) at ruby.__dash_e__.block_0$RUBY$__block__(-e:1) at ruby.__dash_e__BlockCallback$block_0$RUBY$__block__xx1.call(Unknown Source) at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:125) at org.jruby.runtime.BlockBody.call(BlockBody.java:72) at org.jruby.runtime.BlockBody.call(BlockBody.java:78) at org.jruby.runtime.Block.call(Block.java:89) at org.jruby.RubyProc.call(RubyProc.java:221) at org.jruby.RubyProc.call(RubyProc.java:204) at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:94) at java.lang.Thread.run(Thread.java:637) Marking 1.x+ and HelpWanted.
        Hide
        Charles Oliver Nutter added a comment -

        It's also worth mentioning that none of the examples of this happening in the wild seem to be affecting the server, and could simply be unneeded death noise from a thread timing out. If there's a report of this happening in the wild again, we'll try to bump up priority. If there's a report of this actually causing harm in the wild, we will definitely prioritize.

        Show
        Charles Oliver Nutter added a comment - It's also worth mentioning that none of the examples of this happening in the wild seem to be affecting the server, and could simply be unneeded death noise from a thread timing out. If there's a report of this happening in the wild again, we'll try to bump up priority. If there's a report of this actually causing harm in the wild, we will definitely prioritize.
        Hide
        Rick Ohnemus added a comment -

        I thought I had posted most information about what I saw happening. However, since I don't see it in the comments, that must have been when I was having network problems and then completely forgot about posting a comment when the network came back.

        I was only seeing this happen on 2 Windows systems. Everything worked fine on 3 other Windows systems and 2 Linux systems. I couldn't find any significant differences between any of the Windows systems (Windows Server 2003 with the same patches, etc.).

        The error happened on line 1610 of lib/ruby/1.8/drb/drb.rb when DRb was started with 0.0.0.0 in the URL (e.g. "druby://0.0.0.0:12345"). No idea why 0.0.0.0 worked on most systems and caused the break jump error on 2 systems. Removing 0.0.0.0 from the URL allowed the code to work on all systems.

        Show
        Rick Ohnemus added a comment - I thought I had posted most information about what I saw happening. However, since I don't see it in the comments, that must have been when I was having network problems and then completely forgot about posting a comment when the network came back. I was only seeing this happen on 2 Windows systems. Everything worked fine on 3 other Windows systems and 2 Linux systems. I couldn't find any significant differences between any of the Windows systems (Windows Server 2003 with the same patches, etc.). The error happened on line 1610 of lib/ruby/1.8/drb/drb.rb when DRb was started with 0.0.0.0 in the URL (e.g. "druby://0.0.0.0:12345"). No idea why 0.0.0.0 worked on most systems and caused the break jump error on 2 systems. Removing 0.0.0.0 from the URL allowed the code to work on all systems.
        Hide
        Charles Oliver Nutter added a comment -

        Rick: Ok, thank you for the update. It could still be broken, since the default bind URL may have changed due to other fixes. I'll have a second look at the lines you mention from drb.rb and see if I can come up with a reproduction case.

        Show
        Charles Oliver Nutter added a comment - Rick: Ok, thank you for the update. It could still be broken, since the default bind URL may have changed due to other fixes. I'll have a second look at the lines you mention from drb.rb and see if I can come up with a reproduction case.
        Hide
        Charles Oliver Nutter added a comment -

        Rick: I've still been unable to reproduce this. Two questions for you:

        • Can you still reproduce this on any version of JRuby?
        • What priority do you think should be assigned to this issue?
        Show
        Charles Oliver Nutter added a comment - Rick: I've still been unable to reproduce this. Two questions for you: Can you still reproduce this on any version of JRuby? What priority do you think should be assigned to this issue?
        Hide
        Hiro Asari added a comment -

        Rick and Ben,

        Is this still observed in 1.5.0? Or better yet, in the current trunk?

        Show
        Hiro Asari added a comment - Rick and Ben, Is this still observed in 1.5.0? Or better yet, in the current trunk?
        Hide
        Charles Oliver Nutter added a comment -

        No follow-up from any reporters in two years.

        Show
        Charles Oliver Nutter added a comment - No follow-up from any reporters in two years.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Charles Oliver Nutter
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: