This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
CallbackSystemActionTest does not finish all the time which is impossible as the test has timeout in itself and has to finish after each 5s. Please find the root cause of the failure
Created attachment 31500 [details] The statistic of the failure
Why xtest does not provide link to workdir when the test does not finish? The workdir is there, created, but the xtest does not link to it. That is stange.
Because XTest is checking whether workdir was used or not in TestListener.endTest(). And it is never called when test crashes.
I am not saying the xtest has to be fixed, but I need to find out what is happening with the failing test runs. Does anyone has access to those machines, can you run the tests by hand? Attach thread dump, etc.?
Next failure: http://beetle.czech:8080/unittest/TestCase.jsp?issues=3735
Created attachment 31722 [details] the test deadlocked
Ok, I've managed to simulate the problem. There is a deadlock between two(!) finalizer threads and AWT one. However shall not the xtest time the test out, generate thread dump and report it?
I have similar problem, my test randomly failed with "Suite is not finished": http://ffjqa.czech/automatedtests/xtest/netbeans_5.5/200607130000/qa-unit/qa-linux-s1/testrun_060713-052259/testbag_6/htmlresults/suites/TEST-org.openide.explorer.view.TreeView48993Test.html I can't evaluate the failure w/o additional info, I need a thread dump from that state as well.
XTest generates thread dump only when run in IDE mode. I will try to look at possibility to generate thread dump when running in jvm mode.
Another failure: http://beetle.czech:8080/unittest/TestCase.jsp?issues=2053
I have added basic ability to generate thread dumps to the NbTestCase itself. But this may not be enough as the java usually deadlocks itself and then it prints nothing. -- IDE: [15.8.06 14:02] Committing "NB JUnit" started Checking in test/unit/src/org/netbeans/junit/TimeOutHasToPrintLogTest.java; /shared/data/ccvs/repository/xtest/nbjunit/test/unit/src/org/netbeans/junit/TimeOutHasToPrintLogTest.java,v <-- TimeOutHasToPrintLogTest.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/netbeans/junit/Log.java; /shared/data/ccvs/repository/xtest/nbjunit/src/org/netbeans/junit/Log.java,v <-- Log.java new revision: 1.10; previous revision: 1.9 done Checking in src/org/netbeans/junit/NbTestCase.java; /shared/data/ccvs/repository/xtest/nbjunit/src/org/netbeans/junit/NbTestCase.java,v <-- NbTestCase.java new revision: 1.50; previous revision: 1.49
Fixed. Not thread dump is printed out and process is killed when xtest.timeout expires. Checking in plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JVMExecuteWatchdog.java; /cvs/xtest/plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JVMExecuteWatchdog.java,v <-- JVMExecuteWatchdog.java initial revision: 1.1 done Checking in plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JVMTestRunnerTask.java; /cvs/xtest/plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JVMTestRunnerTask.java,v <-- JVMTestRunnerTask.java new revision: 1.8; previous revision: 1.7 done Checking in plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JUnitTestRunnerLauncher.java; /cvs/xtest/plugins_src/jvm/src/org/netbeans/xtest/plugin/jvm/JUnitTestRunnerLauncher.java,v <-- JUnitTestRunnerLauncher.java new revision: 1.6; previous revision: 1.5
One of my test cases is still failing on timeout w/o any thread dump provided. See (internal) http://beetle.czech:8080/unittest/TestCase.jsp?issues=2641
Please, look at latest results. A thread dump produced by NbTestCase is here: http://beetle.czech/automatedtests/xtest/netbeans_dev/200609091800/qa-unit/qa-sol10-s5_1/testrun_060910-220556/logs/core_execution_unit.log A real thread dump would be generated if a test case is locked but timeout is not set in NbTestCase.
This seems to be fixed, I can see the thread dump. Looks like a deadlock in AWT on solaris...
Reassigning to Petr to fix.
Created attachment 33804 [details] Log with thread dump
Imho, the problematic part is: [jvmTestRunner] sun.misc.Unsafe.park:-2 [jvmTestRunner] java.util.concurrent.locks.LockSupport.park:158 [jvmTestRunner] java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt:712 [jvmTestRunner] java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued:743 [jvmTestRunner] java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire:1079 [jvmTestRunner] java.util.concurrent.locks.ReentrantLock$NonfairSync.lock:186 [jvmTestRunner] java.util.concurrent.locks.ReentrantLock.lock:262 [jvmTestRunner] sun.awt.SunToolkit.awtLock:245 [jvmTestRunner] sun.awt.X11.XWM.removeSizeHints:720 [jvmTestRunner] sun.awt.X11.XDecoratedPeer.setVisible:920 [jvmTestRunner] sun.awt.X11.XFramePeer.setVisible:275 Petr, do you have more insight to what is going on?
I don't understand few things now. First, it was really far from obvious to get from the failure to the build log, where the thread dump indeed was. Why isn't the thread dump part of the failure message? Well, it is generated just a line before triggering the test failure anyway! (org.netbeans.junit.NbTestCase$1Guard.waitFinished:212) And when we're at it, can the infractructure list the threads hierarchically (i.e. according to their nested thread groups)? It could help me diagnose this issue by making sure there is no runaway thread in the execution ThreadGroup... Second, if I don't specify the timeout, it would provide real (SIGQUIT) thread dump after some default timeout? How long is that timeout? Third, I really don't understand what's going on in the log from 20060909 (it might as well still be processing), but the latest log from 20060911 looks like the engine doesn't recoginzed the processing is over, which may be due to wrong synchronization is TaskThreadGroup.waitFor; I'll try to fix the synchronization problem, just to be sure, while I think it is mostly hypothetical. Thanks for wide cooperation.
Imroved synchronization: core/execution/src/org/netbeans/core/execution/TaskThreadGroup.java,v1.7 Jirko, please see my previous comment. I haven't realize you're not on CC anymore.
ad 1) It is a question for Jarda who added thread dumping feature to NbTestCase. ad 2) Yes. xtest.timeout=2400000 (40 minutes)
ad1) go on, write a test and better impl in NbTestCase if you want.
Failed again w/o visible reason. I'll improve the deadlock reporting infrastructure.
Better thread dump reporting implemented: xtest/nbjunit/src/org/netbeans/junit/Log.java,v1.11 xtest/nbjunit/src/org/netbeans/junit/NbTestCase.java,v1.55 xtest/nbjunit/test/unit/src/org/netbeans/junit/TimeOutHasToPrintLogTest.java,v1.3 Jirko, can you ensure it gets deployed quickly onto the testing machines, please?
Test failed again. The failure is caused by AWT shudwown thread sneaking into execution thread group.
Forced the AWT shutdown thread to stay in proper thread group and not leak into the execution TG. core/execution/test/unit/src/org/netbeans/core/execution/TaskThreadGroupGCTest.java,v1.7
testTTGGC: java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:851) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1257) at org.netbeans.core.execution.TaskThreadGroupGCTest.setUp(TaskThreadGroupGCTest.java:46) at org.netbeans.junit.NbTestCase.runBare(NbTestCase.java:274) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:161) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:173) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:124) at org.netbeans.xtest.plugin.jvm.JUnitTestRunnerLauncher.main(JUnitTestRunnerLauncher.java:60) Caused by: java.lang.IllegalArgumentException: null owner window at java.awt.Window.ownedInit(Window.java:414) at java.awt.Window.<init>(Window.java:346) at java.awt.Dialog.<init>(Dialog.java:222) at java.awt.Dialog.<init>(Dialog.java:177) at org.netbeans.core.execution.TaskThreadGroupGCTest$1.run(TaskThreadGroupGCTest.java:48) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
AWT doesn't like null-parent dialogs: core/execution/test/unit/src/org/netbeans/core/execution/TaskThreadGroupGCTest.java,v1.8