Harmony
  1. Harmony
  2. HARMONY-1823

[drlvm][unit] VM throws RuntimeException in AWT-EventDispatchThread

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DRLVM
    • Labels:
      None

      Description

      Problems:

      VM throws RuntimeException in AWT-EventDispatchThread with JET and OPT on all platforms

      Code for reproducing:

      import java.awt.*;

      public class Test {

      public static void main(String argv[])

      { new TestA().testTest(); }

      public void testTest()

      { new ScrollPane(); new Button(); }

      }

      Output on Harmony:

      Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
      java version "1.5.0"
      pre-alpha : not complete or compatible
      svn = r454551, (Oct 11 2006), Windows/ia32/msvc 1310, release build
      http://incubator.apache.org/harmony
      java.lang.RuntimeException: Shutdown thread was interrupted while stopping
      at org.apache.harmony.awt.wtk.ShutdownThread.shutdown(ShutdownThread.java:72)
      at org.apache.harmony.awt.wtk.ShutdownWatchdog.shutdown(ShutdownWatchdog.java:81)
      at org.apache.harmony.awt.wtk.ShutdownWatchdog.checkShutdown(ShutdownWatchdog.java:61)
      at org.apache.harmony.awt.wtk.ShutdownWatchdog.setAwtQueueEmpty(ShutdownWatchdog.java:42)
      at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:82)
      at java.awt.EventDispatchThread.run(EventDispatchThread.java:45)
      Uncaught exception in AWT-EventDispatchThread:
      java.lang.RuntimeException: Shutdown thread was interrupted while stopping
      at org.apache.harmony.awt.wtk.ShutdownThread.shutdown(ShutdownThread.java:72)
      at org.apache.harmony.awt.wtk.ShutdownWatchdog.shutdown(ShutdownWatchdog.java:81)
      at org.apache.harmony.awt.wtk.ShutdownWatchdog.forceShutdown(ShutdownWatchdog.java:52)
      at java.awt.EventDispatchThread.run(EventDispatchThread.java:53)

      1. ThreadInterruptTest.java
        3 kB
        Alexei Fedotov
      2. ThreadInterruptTest.java
        3 kB
        Alexei Fedotov
      3. InterruptTest.java
        1 kB
        Nikolay Kuznetsov
      4. states.patch
        0.8 kB
        Nikolay Kuznetsov
      5. interrupt_fix.patch
        2 kB
        Nikolay Kuznetsov
      6. SingleInterruptTest.java
        0.7 kB
        Dmitry A. Durnev

        Issue Links

          Activity

          Hide
          Maxim Makarov added a comment -
          Show
          Maxim Makarov added a comment - [drlvm] [unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
          Hide
          Dmitry A. Durnev added a comment -

          Issue is caused by throwing multiple InterruptedExceptions on single Thread.interrupt() call. Minimum test case is attached.

          Show
          Dmitry A. Durnev added a comment - Issue is caused by throwing multiple InterruptedExceptions on single Thread.interrupt() call. Minimum test case is attached.
          Hide
          Nikolay Kuznetsov added a comment -

          Attached patch fixes this issue. The problem was reproduced by HARMONY-1383. The problem here is that wait, join and sleep handles interrupts the way different to park, which does not throw interrupted exception.

          In ideal world all the waiting should be based on park method and thread should carry interrupted status till wait, sleep, join or interrupted method call. That's probably why the interrupted status was restored in HARMONY-1383.

          In DRLVM park based on the same condition primitive as wait, sleep, or join, since it's only one method I believe that we should treat park as special case and restore interrupted status as needed.

          Note tests attached to HARMONY-1383 should still pass of 'cause.

          Show
          Nikolay Kuznetsov added a comment - Attached patch fixes this issue. The problem was reproduced by HARMONY-1383 . The problem here is that wait, join and sleep handles interrupts the way different to park, which does not throw interrupted exception. In ideal world all the waiting should be based on park method and thread should carry interrupted status till wait, sleep, join or interrupted method call. That's probably why the interrupted status was restored in HARMONY-1383 . In DRLVM park based on the same condition primitive as wait, sleep, or join, since it's only one method I believe that we should treat park as special case and restore interrupted status as needed. Note tests attached to HARMONY-1383 should still pass of 'cause.
          Hide
          Elena Semukhina added a comment -

          I tried the patch together with HARMONY-1816 and HARMONY-1823.
          They eiminate recent classlib tests pass rate degradation.
          drlvm smoke, cunit, kernel pass.

          Show
          Elena Semukhina added a comment - I tried the patch together with HARMONY-1816 and HARMONY-1823 . They eiminate recent classlib tests pass rate degradation. drlvm smoke, cunit, kernel pass.
          Hide
          Elena Semukhina added a comment -

          Sorry for typo above: I tried the patch together with HARMONY-1816 and HARMONY-1592.

          Show
          Elena Semukhina added a comment - Sorry for typo above: I tried the patch together with HARMONY-1816 and HARMONY-1592 .
          Hide
          Geir Magnusson Jr added a comment -

          I can't get either the test in comment, or the attached test to fail as of r463973 on Ubuntu 6

          Can you verify there still is a bug?

          Show
          Geir Magnusson Jr added a comment - I can't get either the test in comment, or the attached test to fail as of r463973 on Ubuntu 6 Can you verify there still is a bug?
          Hide
          Elena Semukhina added a comment -

          The test in comment passed for me too while the attached test failed on Windows and linux. It printed
          int0:Thread[Thread-5,5,main]
          int1:Thread[Thread-5,5,main]
          ...
          int14:Thread[Thread-5,5,main]

          The patch makes the test pass. It now prints

          int0:Thread[Thread-5,5,main]
          waited 100 ms
          waited 100 ms
          ...
          waited 100 ms

          Show
          Elena Semukhina added a comment - The test in comment passed for me too while the attached test failed on Windows and linux. It printed int0:Thread [Thread-5,5,main] int1:Thread [Thread-5,5,main] ... int14:Thread [Thread-5,5,main] The patch makes the test pass. It now prints int0:Thread [Thread-5,5,main] waited 100 ms waited 100 ms ... waited 100 ms
          Hide
          Alexey Varlamov added a comment -

          Just for the record: the patch changes statistics for kernel j.l.ThreadTest.
          Before patch:
          There were 3 failures:
          1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared
          at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1369)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)
          2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared
          at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1392)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)
          3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared
          at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1415)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)

          After patch:
          Testcase: testInterrupt_RunningThread(java.lang.ThreadTest): FAILED
          interrupt status has not changed to true
          junit.framework.AssertionFailedError: interrupt status has not changed to true
          at junit.framework.Assert.fail(Assert.java:47)
          at java.lang.ThreadTest.testInterrupt_RunningThread(ThreadTest.java:1299)

          Looks like patch has undesirable side effect

          Show
          Alexey Varlamov added a comment - Just for the record: the patch changes statistics for kernel j.l.ThreadTest. Before patch: There were 3 failures: 1) testInterrupt_Joining(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared at java.lang.ThreadTest.testInterrupt_Joining(ThreadTest.java:1369) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testInterrupt_Sleeping(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared at java.lang.ThreadTest.testInterrupt_Sleeping(ThreadTest.java:1392) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 3) testInterrupt_Waiting(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not been cleared at java.lang.ThreadTest.testInterrupt_Waiting(ThreadTest.java:1415) at java.lang.reflect.VMReflection.invokeMethod(Native Method) After patch: Testcase: testInterrupt_RunningThread(java.lang.ThreadTest): FAILED interrupt status has not changed to true junit.framework.AssertionFailedError: interrupt status has not changed to true at junit.framework.Assert.fail(Assert.java:47) at java.lang.ThreadTest.testInterrupt_RunningThread(ThreadTest.java:1299) Looks like patch has undesirable side effect
          Hide
          Alexey Varlamov added a comment -

          Hmm, actually there are intermittent failures, sometimes test PASS...
          There were 2 failures:
          1) testGetStateBlocked(java.lang.ThreadTest)junit.framework.AssertionFailedError: BLOCKED state has not been set
          at java.lang.ThreadTest.testGetStateBlocked(ThreadTest.java:1041)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)
          2) testIsInterrupted(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not changed to true
          at java.lang.ThreadTest.testIsInterrupted(ThreadTest.java:1521)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)

          Looking closer, these cannot be caused by the patch. Therefore +1 to interrupt_fix.patch, it eliminates many test failures in AWT / SWING tests.

          Show
          Alexey Varlamov added a comment - Hmm, actually there are intermittent failures, sometimes test PASS... There were 2 failures: 1) testGetStateBlocked(java.lang.ThreadTest)junit.framework.AssertionFailedError: BLOCKED state has not been set at java.lang.ThreadTest.testGetStateBlocked(ThreadTest.java:1041) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testIsInterrupted(java.lang.ThreadTest)junit.framework.AssertionFailedError: interrupt status has not changed to true at java.lang.ThreadTest.testIsInterrupted(ThreadTest.java:1521) at java.lang.reflect.VMReflection.invokeMethod(Native Method) Looking closer, these cannot be caused by the patch. Therefore +1 to interrupt_fix.patch, it eliminates many test failures in AWT / SWING tests.
          Hide
          Elena Semukhina added a comment -

          The test ThreadTest.testGetStateBlocked() is not quite correct. I filed HARMONY-1876 to fix the test.

          Show
          Elena Semukhina added a comment - The test ThreadTest.testGetStateBlocked() is not quite correct. I filed HARMONY-1876 to fix the test.
          Hide
          Sergey Soldatov added a comment -

          Hm. I'm trying to run Netbeans IDE with Harmony and even with this patch I can see the same failures during the startup.

          Show
          Sergey Soldatov added a comment - Hm. I'm trying to run Netbeans IDE with Harmony and even with this patch I can see the same failures during the startup.
          Hide
          Sergey Soldatov added a comment -

          Well, it was a bit different problem, so my troubles are not related to this issue.

          Show
          Sergey Soldatov added a comment - Well, it was a bit different problem, so my troubles are not related to this issue.
          Hide
          Nikolay Kuznetsov added a comment -

          Geir,
          this still a problem lots of awt and swing tests fails because of this problem. The essence of this issue is that after H-1383 was integrated we do not clean interrupted state in any other place any more.

          Attached add-on to the original patch also removes wrong thread state cleanup at startup. While we have asynch thread start this state cleanup is just wrong.

          Show
          Nikolay Kuznetsov added a comment - Geir, this still a problem lots of awt and swing tests fails because of this problem. The essence of this issue is that after H-1383 was integrated we do not clean interrupted state in any other place any more. Attached add-on to the original patch also removes wrong thread state cleanup at startup. While we have asynch thread start this state cleanup is just wrong.
          Hide
          Geir Magnusson Jr added a comment -

          which patch do you want? one or both?

          Show
          Geir Magnusson Jr added a comment - which patch do you want? one or both?
          Hide
          Alexey Varlamov added a comment -

          I believe both patches are useful at the moment, please commit both.
          On a side note, I have unpleasant feeling that some real problems in TM are just being hacked around. Either I'm wrong or we'll encounter new troubles in this area soon enough...

          Show
          Alexey Varlamov added a comment - I believe both patches are useful at the moment, please commit both. On a side note, I have unpleasant feeling that some real problems in TM are just being hacked around. Either I'm wrong or we'll encounter new troubles in this area soon enough...
          Hide
          Geir Magnusson Jr added a comment -

          I'm terrified of this too. Of the two test cases,I could only get the one in comments to fail once, and once only, and the attached one never. This seems that we're just hacking around rather than understanding full spectrum and getting at root cause.

          If you all still believe that these patches are good, I'll commit them, but right now, I have no real way of verifying the failure or the solution,

          Show
          Geir Magnusson Jr added a comment - I'm terrified of this too. Of the two test cases,I could only get the one in comments to fail once, and once only, and the attached one never. This seems that we're just hacking around rather than understanding full spectrum and getting at root cause. If you all still believe that these patches are good, I'll commit them, but right now, I have no real way of verifying the failure or the solution,
          Hide
          Gregory Shimansky added a comment -

          For me this patch has fixed kernel test j.l.ObjectTest. It failed because interrupt wasn't working on wait, now this test passes. But for me kernel test j.l.ThreadTest fails with 2 new errors:

          1) testYield(java.lang.ThreadTest)junit.framework.AssertionFailedError: threads have not yielded
          at java.lang.ThreadTest.testYield(ThreadTest.java:775)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)
          2) testJoinlongint(java.lang.ThreadTest)junit.framework.AssertionFailedError: join should wait for at least 2000999999 but waited for 2000000000
          at java.lang.ThreadTest.testJoinlongint(ThreadTest.java:1565)
          at java.lang.reflect.VMReflection.invokeMethod(Native Method)

          This test also fails on jrockit 1.5.0 like this:

          1) testInterrupt_New(java.lang.ThreadTest)java.lang.NullPointerException
          at java.lang.Thread.interrupt0()V(Unknown Source)
          at java.lang.Thread.interrupt()V(Unknown Source)
          at java.lang.ThreadTest.testInterrupt_New(ThreadTest.java:1272)
          at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)

          so maybe it is not completely correct.

          I tried patches both on windows and on linux.

          Show
          Gregory Shimansky added a comment - For me this patch has fixed kernel test j.l.ObjectTest. It failed because interrupt wasn't working on wait, now this test passes. But for me kernel test j.l.ThreadTest fails with 2 new errors: 1) testYield(java.lang.ThreadTest)junit.framework.AssertionFailedError: threads have not yielded at java.lang.ThreadTest.testYield(ThreadTest.java:775) at java.lang.reflect.VMReflection.invokeMethod(Native Method) 2) testJoinlongint(java.lang.ThreadTest)junit.framework.AssertionFailedError: join should wait for at least 2000999999 but waited for 2000000000 at java.lang.ThreadTest.testJoinlongint(ThreadTest.java:1565) at java.lang.reflect.VMReflection.invokeMethod(Native Method) This test also fails on jrockit 1.5.0 like this: 1) testInterrupt_New(java.lang.ThreadTest)java.lang.NullPointerException at java.lang.Thread.interrupt0()V(Unknown Source) at java.lang.Thread.interrupt()V(Unknown Source) at java.lang.ThreadTest.testInterrupt_New(ThreadTest.java:1272) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) so maybe it is not completely correct. I tried patches both on windows and on linux.
          Hide
          Alexei Fedotov added a comment -

          > On a side note, I have unpleasant feeling that some real problems in TM are just being hacked around. Either I'm wrong or we'll encounter new troubles in this area soon enough...

          I don't think it is a hack. For me it looks like the initial implementation lacks processing thread state flag in case of interrupt. From the other side errors like this make me think we need to have more very simple tests for threading.

          Show
          Alexei Fedotov added a comment - > On a side note, I have unpleasant feeling that some real problems in TM are just being hacked around. Either I'm wrong or we'll encounter new troubles in this area soon enough... I don't think it is a hack. For me it looks like the initial implementation lacks processing thread state flag in case of interrupt. From the other side errors like this make me think we need to have more very simple tests for threading.
          Hide
          Nikolay Kuznetsov added a comment -

          1. Attach test demonstrated the problem both on windows and linux, the valid output should be:
          m:started
          m:interrupted
          Test passed
          In case of failure it prints(if patches not applied):
          m:started
          m:interrupted
          Test failed: thread was interrupted, but interrupted state was not cleared
          2. I beg your pardon but all kernel tests passed for me after applying this patch, I verified the build also both on linux(P4 Ubuntu linux) and windows(Win 2003, Xeon)
          3.AWT test fails mostly on Windows

          Fellows, please, give this patch a green light, this thing is really important for awt/swing applications.

          Show
          Nikolay Kuznetsov added a comment - 1. Attach test demonstrated the problem both on windows and linux, the valid output should be: m:started m:interrupted Test passed In case of failure it prints(if patches not applied): m:started m:interrupted Test failed: thread was interrupted, but interrupted state was not cleared 2. I beg your pardon but all kernel tests passed for me after applying this patch, I verified the build also both on linux(P4 Ubuntu linux) and windows(Win 2003, Xeon) 3.AWT test fails mostly on Windows Fellows, please, give this patch a green light, this thing is really important for awt/swing applications.
          Hide
          Salikh Zakirov added a comment -

          I encountered the same problem and have filed HARMONY-1923 for the same problem.
          The half of interrupt_fix.patch fixes the test for me (HARMONY-1923/Test.java is similar to SingleInterrupt.java),
          and both cunit and smoke tests pass for me.

          Show
          Salikh Zakirov added a comment - I encountered the same problem and have filed HARMONY-1923 for the same problem. The half of interrupt_fix.patch fixes the test for me ( HARMONY-1923 /Test.java is similar to SingleInterrupt.java), and both cunit and smoke tests pass for me.
          Hide
          Salikh Zakirov added a comment -

          HARMONY-1923/Test.java provides reproducer for the problem, which detects the failure automatically and prints either PASSED or FAILED

          Show
          Salikh Zakirov added a comment - HARMONY-1923 /Test.java provides reproducer for the problem, which detects the failure automatically and prints either PASSED or FAILED
          Hide
          Alexei Fedotov added a comment -

          This is a regression test for this issue. Test is to be placed vm/tests/kernel/java/lang and will run automatically.

          To compile test use
          $ ( cd drlvm/build; sh build.sh kernel.test )
          ^C when get the message
          ==================================
          Run kernel tests using jitrino.jet
          ==================================

          To run the test use
          drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -Xbootclasspath/a:drlvm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes:drlvm/build/make/tmp/junit.jar
          junit.textui.TestRunner java.lang.ThreadInterruptTest

          It was fun to implement conditional variables in Java.

          Show
          Alexei Fedotov added a comment - This is a regression test for this issue. Test is to be placed vm/tests/kernel/java/lang and will run automatically. To compile test use $ ( cd drlvm/build; sh build.sh kernel.test ) ^C when get the message ================================== Run kernel tests using jitrino.jet ================================== To run the test use drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -Xbootclasspath/a:drlvm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes:drlvm/build/make/tmp/junit.jar junit.textui.TestRunner java.lang.ThreadInterruptTest It was fun to implement conditional variables in Java.
          Hide
          Alexei Fedotov added a comment -

          Removed infinite loop waiting for conditional variable, added descriptive method names.

          Show
          Alexei Fedotov added a comment - Removed infinite loop waiting for conditional variable, added descriptive method names.
          Hide
          Geir Magnusson Jr added a comment -

          Can someone summarzie where we are?

          Show
          Geir Magnusson Jr added a comment - Can someone summarzie where we are?
          Hide
          Nikolay Kuznetsov added a comment -

          Well, if you still believe me...
          1. InterruptTest.java demonstrates the problem both on windows and linux, for now it prints:
          m:started
          m:interrupted
          Test failed: thread was interrupted, but interrupted state was not cleared

          2. Both patches should be applied(interrupt_fix.patch & states.patch), after applying them the test will print:
          m:started
          m:interrupted
          Test passed

          Note:
          1.The patches have different relative paths (interrupt_fix.patch have paths started with trunk, while states.patch from vm), sorry for that;
          2.after applying the patch the test works a bit longer, this is expected behavior;

          Show
          Nikolay Kuznetsov added a comment - Well, if you still believe me... 1. InterruptTest.java demonstrates the problem both on windows and linux, for now it prints: m:started m:interrupted Test failed: thread was interrupted, but interrupted state was not cleared 2. Both patches should be applied(interrupt_fix.patch & states.patch), after applying them the test will print: m:started m:interrupted Test passed Note: 1.The patches have different relative paths (interrupt_fix.patch have paths started with trunk, while states.patch from vm), sorry for that; 2.after applying the patch the test works a bit longer, this is expected behavior;
          Hide
          Geir Magnusson Jr added a comment -

          r467446

          Ubuntu 6 - passes JIRA testcase, c-unit, smoke, and ~kernel

          Show
          Geir Magnusson Jr added a comment - r467446 Ubuntu 6 - passes JIRA testcase, c-unit, smoke, and ~kernel
          Hide
          Alexei Fedotov added a comment -

          Geir,
          Just want to make sure you didn't miss that. I have created a regression test (kernel test) which could be committed to vm/tests/kernel/java/lang along with the patch. http://issues.apache.org/jira/secure/attachment/12343348/ThreadInterruptTest.java

          This is not definitely not a must, but you were interested in the test.

          Show
          Alexei Fedotov added a comment - Geir, Just want to make sure you didn't miss that. I have created a regression test (kernel test) which could be committed to vm/tests/kernel/java/lang along with the patch. http://issues.apache.org/jira/secure/attachment/12343348/ThreadInterruptTest.java This is not definitely not a must, but you were interested in the test.

            People

            • Assignee:
              Geir Magnusson Jr
              Reporter:
              Maxim Makarov
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development