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.
Since yesterday I am not able to correctly finish ant -f openide/test/build.xml test suite as some of the pixel counting property tests deadlocks due to incorrect handling of assertions. Please make the infrastructure more robust (not to deadlock) and probably also fix the test.
Created attachment 12539 [details] Stacktraces
Ugh. I tried to fix it so it would work for Petr Kuzel, and apparently my fix broke it. And of course, it works fine on a multiprocessor machine...
I just removed some synchronization in the test which was probably the problem (I should have removed it when I made the fix for Peter). Try it now and close this issue if it works.
Created attachment 12550 [details] Problem is in invokeAndWait
Okay. When I did my first commit, I hadn't saved the file, so NetBeans semi-silently did nothing (there was a commit tab open offscreen...). So I did a second commit with the change about 20 minutes later. So I don't understand - did you commit the patch you attached?
Jarda, when I run with your patch I have no problems - but I also had no problems before.
That is fine, my test is just improving the error handling. Do you want to try the problem? Then put: fail ("For no reason"); on the line 336 (as indicated by the log file). Run with and without my patch. As you may remember I have other problems with fonts on my computer, so you may want to stop by and investigate why the test fails on here. But that is something my patch does not try to solve at all.
Okay. I integrated your patch by the way. So is the test now failing, or deadlocking, or failing because it deadlocks? :-) AFAIK it was the synchronization that caused at least a potential deadlock; is there something else?
"So is the test now failing?" Yes. It is failing: junit.framework.AssertionFailedError: Color at 154,88 does not match expected:<java.awt.Color[r=208,g=0,b=0]> but was:<java.awt.Color[r=255,g=0,b=0]> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at org.openide.explorer.propertysheet.PropertyMarkingTest.doAssertPixel(PropertyMarkingTest.java:343) at org.openide.explorer.propertysheet.PropertyMarkingTest.access$100(PropertyMarkingTest.java:56) at org.openide.explorer.propertysheet.PropertyMarkingTest$4.run(PropertyMarkingTest.java:299)
I should see it run on your machine. It probably is a result of your font size problem. Probably (along with the test for 8 bit color), I should run some kind of test of default font height, and if it's above the default icon size, not run the test.
AFAIK there is no deadlock, and the test now checks the pixel height of the default font, and if it's something taller than the standard icon height, the test won't be run. So I think we can close this issue. There are some problems with other property sheet tests - I'll address them shortly. Any idea how to detect what window manager somebody's running? Most tests are fine on Solaris (CDE or Blackbox), Windows and *most* window managers on Linux (with the exception of SawFish and anything that uses focus-follows-mouse). So I'm looking for some way to figure it out. Perhaps run some generic pop-up a dialog and see what gets focus test. If the dialog doesn't probably other tests will fail too.
Re. WM test: I need to know whether I am on KDE or GNOME as well, but I have no idea how to do it as Env-KDE or other variables do not seem to work reliably.
Hmm, maybe the only way is to run ps as an external process and parse the output for known window managers. Still doesn't get version info which could be important, but it's at least something. I'll try my preliminary focus-behavior test, and see if I can find a way to make it reliable enough to predict whether it's safe to run focus-dependent tests or not.
Marking fixed - deadlock is gone.
verified