JRuby

'Thread.main.exit!' and/or 'Kernel.exit!' does not work under certain circumstances

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.0.0, JRuby 1.1b1
  • Fix Version/s: JRuby 1.0.2, JRuby 1.1b1
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    Linux
  • Number of attachments :
    4

Description

I'm trying to solve problem why classic debugger in debug-commons does not exit under Windows. It is caused by the fact that 'Kernel.exit!' does not exit the underlaying process. As trying to reproduce with simple test-case I've got to the following one under Linux which might be related to the Windows problem. Not sure, the one under Windows might be different.

Following code exit under C Ruby but not under JRuby (running Linux). It might cause by the 'next' call somehow .

terminator = Thread.new do
  sleep 2
  puts 'exit'
  exit!
end
Kernel.module_eval(<<-"end;"
      alias_method(:debug_commons_set_trace_func, :set_trace_func)
      def set_trace_func(proc)
        raise "Cannot call 'set_trace_func' method during debugging session."
      end
  end;
)
debug_commons_set_trace_func(lambda do |_, _, _, _, _, _|
  next if Thread.current == terminator
  loop do
    puts Thread.current.object_id
    sleep 1
  end
end)
p "whatever...."

Attachments

  1. Text File
    exit_rev2.trunk.patch
    29/Oct/07 9:59 PM
    6 kB
    Peter Brant
  2. Text File
    exit.jruby-1_0.patch
    29/Oct/07 3:08 PM
    3 kB
    Pon Hwa Lin
  3. Text File
    exit.patch
    11/Oct/07 7:26 PM
    6 kB
    Peter Brant
  4. Text File
    exit.trunk.patch
    29/Oct/07 3:08 PM
    6 kB
    Pon Hwa Lin

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Krauskopf added a comment -

Aliasing is not needed actually in the code snipped. This issue is particularly critical for GUI debugger, since they are not able to kill debugging session. But I would bet that this is regression in debug-commons - it worked in the past. But not so sure now. Anyway evaluating this issue quickly would really help me

Show
Martin Krauskopf added a comment - Aliasing is not needed actually in the code snipped. This issue is particularly critical for GUI debugger, since they are not able to kill debugging session. But I would bet that this is regression in debug-commons - it worked in the past. But not so sure now. Anyway evaluating this issue quickly would really help me
Hide
Permalink
Martin Krauskopf added a comment -

Even following:

Thread.new do
  sleep 2
  puts 'exiting...'
  Kernel.exit!
end
loop do
  puts "looping..."
  sleep 1
end
p "whatever...."

will never exit. Try to run under MRI and JRuby (tried with Linux and Windows). It is possible to increase priority of the issue in JIRA for the user? This is really bad for the debugger.

Show
Martin Krauskopf added a comment - Even following: 
Thread.new do
  sleep 2
  puts 'exiting...'
  Kernel.exit!
end
loop do
  puts "looping..."
  sleep 1
end
p "whatever...."
will never exit. Try to run under MRI and JRuby (tried with Linux and Windows). It is possible to increase priority of the issue in JIRA for the user? This is really bad for the debugger.
Hide
Permalink
Peter Brant added a comment -

The attached patch fixes this for me. It makes sure SystemExit is never caught by a rescue (interpreter and compiler) and that SystemExit is propagated back to the main thread.

Show
Peter Brant added a comment - The attached patch fixes this for me. It makes sure SystemExit is never caught by a rescue (interpreter and compiler) and that SystemExit is propagated back to the main thread.
Hide
Permalink
Peter Brant added a comment -

Update for latest trunk

Show
Peter Brant added a comment - Update for latest trunk
Hide
Permalink
Charles Oliver Nutter added a comment -

This passes on trunk (exits immediately) but does appear to run forever on 1.0 branch. I'm not sure whether we can backport whatever fixed this. Can you retest with trunk?

Show
Charles Oliver Nutter added a comment - This passes on trunk (exits immediately) but does appear to run forever on 1.0 branch. I'm not sure whether we can backport whatever fixed this. Can you retest with trunk?
Hide
Permalink
Peter Brant added a comment -

Without the patch, Martin's second example still fails for me on trunk r4673

Show
Peter Brant added a comment - Without the patch, Martin's second example still fails for me on trunk r4673
Hide
Permalink
Martin Krauskopf added a comment -

> Without the patch, Martin's second example still fails for me on trunk r4673

The same for me (tested on Linux now).

Show
Martin Krauskopf added a comment - > Without the patch, Martin's second example still fails for me on trunk r4673 The same for me (tested on Linux now).
Hide
Permalink
Martin Krauskopf added a comment -

And I can confirm that Peter's patch work (tried against JRuby rev. 4558)

Show
Martin Krauskopf added a comment - And I can confirm that Peter's patch work (tried against JRuby rev. 4558)
Hide
Permalink
Charles Oliver Nutter added a comment -

This patch looks great...I have no problem applying it. But it's gotten stale

Would it be possible to get an updated patch for 1.0.2 and 1.1? And 1.0.2 is on the hot seat right now, we need to close the door on changes really soon.

Show
Charles Oliver Nutter added a comment - This patch looks great...I have no problem applying it. But it's gotten stale Would it be possible to get an updated patch for 1.0.2 and 1.1? And 1.0.2 is on the hot seat right now, we need to close the door on changes really soon.
Hide
Permalink
Pon Hwa Lin added a comment -

I've updated the patches supplied by pbrant for both trunk and jruby-1_0, but I'm not familiar enough with the jruby internals to be sure about what work, if any, needs to be done to backport the compiler-related changes for 1.0.2.

Both the trunk and jruby-1_0 patches were built and tested against r4781 on ubuntu 7.10 w/JDK 1.6.0_03.

Show
Pon Hwa Lin added a comment - I've updated the patches supplied by pbrant for both trunk and jruby-1_0, but I'm not familiar enough with the jruby internals to be sure about what work, if any, needs to be done to backport the compiler-related changes for 1.0.2. Both the trunk and jruby-1_0 patches were built and tested against r4781 on ubuntu 7.10 w/JDK 1.6.0_03.
Hide
Permalink
Peter Brant added a comment -

Slightly cleaned up version of current trunk patch that uses isKindOf() vs. ==. Hopefully more future proof.

Show
Peter Brant added a comment - Slightly cleaned up version of current trunk patch that uses isKindOf() vs. ==. Hopefully more future proof.
Hide
Permalink
Charles Oliver Nutter added a comment -

Patch looks pretty clean, so I've applied it to trunk and 1.0 branch. If someone can think of a good way to write a test for this, that would be very nice. Please?

Show
Charles Oliver Nutter added a comment - Patch looks pretty clean, so I've applied it to trunk and 1.0 branch. If someone can think of a good way to write a test for this, that would be very nice. Please?
Hide
Permalink
Charles Oliver Nutter added a comment -

BTW, Pon Hwa Lin: No compiler changes were need in 1.0.2, since it did not compile any try/catch/rescue/ensure code as 1.1 does.

Show
Charles Oliver Nutter added a comment - BTW, Pon Hwa Lin: No compiler changes were need in 1.0.2, since it did not compile any try/catch/rescue/ensure code as 1.1 does.

People

Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.