Bugzilla – Full Text Bug Listing
| Summary: | SWT test failures on Windows 7 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Moir <kim.moir> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | carolynmacleod4, d_a_carver, eclipse.felipe, markus.kell.r, webmaster | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 3.7 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 295393 | ||||||
| Attachments: |
|
||||||
|
Description
Kim Moir
isVisible() seems to work differently on Windows 7. I'll look into it. Besides that, DateTime also have some differences, I'll notify Car about it. Created attachment 181984 [details]
patch to fix DateTime errors
It seems that the DTM_SETSYSTEMTIME message has different behavior in Windows 7.
Apparently I was relying on undocumented behavior for setting certain values.
This patch enforces our API, and does not rely on platform behavior.
It is the same code as for the cocoa implementation of DateTime.
I am not going to release it right away, because we have temporarily frozen HEAD until after M3 ships.
The isVisible() problem does not happen on my machine running the tests manually from my workspace. Maybe it is problem caused by the way the Tests are ran by hudson ? The only difference is that instead of running the tests over rsh, as they are today, they are run locally on the machine. I can't see the UI from here, they are running at the foundation's ISP. Are there any settings on your machine that are different from a default Windows 7 install? Also, the foundation machine is a virtualized instance of Windows 7 on x86_64 hardware. > Are there any settings on your machine
> that are different from a default Windows 7 install?
I don't think so.
(In reply to comment #5) > Also, the foundation machine is a virtualized instance of Windows 7 on x86_64 > hardware. Not sure what to tell you, is anyone able to run the the tests manually (watching the UI while the tests are running) ? I checked the test, and it is correct. But if you need I can disable it for windows 7 (or someother condition). Eclipse webmasters, Is there a way to see the UI remotely on the Windows 7 slave? Is there a screen saver enabled? We are trying to troubleshoot why some SWT tests pass here but fail on eclipse.org's Windows 7 Hudson slave. FYI, I released the patch in comment 2 to HEAD to fix the DateTime test errors. So those tests should pass after tonight's build. (Note that this has nothing to do with the isVisible() problem). I can access the desktop remotely, so I'm willing to run the a test(for testing) if you can tell me exactly what you need done. There isn't a screen saver presently configured. -M. You can run this build and look at the screen and see if there are any error messages https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-JUnit/ I've configured this build so only the SWT tests run I've run that job a few times connecting via rdesktop and 'directly' to the VMs desktop as both administrator and the Hudson user, but I don't see anything on desktop that indicates it's doing anything. Can these tests be run directly without going through Hudson? -M. Matt, yes, you should be able to run them directly from the command line - run testAll.bat from the command line in the directory that corresponds to this url https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-JUnit/ws/2010-11-02_14-16-36/eclipse-testing/testAll.bat/*view*/ Ok, I've run the test script a few times and it seems to get off to a slow start, then a bunch of little windows 'pop' rapidly and it just seems to tick along. I don't see any warning messages(from windows), and some of the test windows are 'empty' but it seems to be ok. -M. Looks like the tests still failed if this file was updated when you ran it https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-JUnit/ws/2010-11-02_14-16-36/eclipse-testing/results/xml/org.eclipse.swt.tests_win32.win32.x86_6.0.xml I can't tell the timestamp of the file from here Yes it was updated. I've just re-run the tests to confirm that. -M. (In reply to comment #16) > Yes it was updated. I've just re-run the tests to confirm that. > -M. I'm understanding is that the test passed when you ran them, right ? No, the tests still failed according to the results page. I was just running the tests to see if any error windows came up. -M. I'll update this with a link to a more recent build when today's test build completes. Here is an updated link https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/JUnit-win/lastCompletedBuild/testReport/org.eclipse.swt.tests.junit/ Sorry for the delay, I couldn't run a test build last week because hudson at eclipse was continually running out of disk space. I ran the tests again on my Windows 7 machine, all passed. I really think the problem is in your setup, how do you suggest we proceed of this bug ? I say someone has to physically seat in front of the machine (no remote desktop or anything like that), install Eclipse 3.7 M5 in it, download SWT from CVS: http://www.eclipse.org/swt/cvs.php download org.eclipse.swt.tests from the CVS the same way. Select org.eclipse.swt.tests/JUnit Tests/org/eclipse/swt/tests/junit/AllTests.java and run it as JUnit test. Can we please try that ? Unfortunately, I can't do that. The machines are in a secure location. Denis has sent me instructions on how to look at ui on the machine via RDP. I'll try that, haven't been able to get that to work yet. > Unfortunately, I can't do that. The machines are in a secure location. We can always go to the data centre, but we'd still be accessing the machine via RDP. > Denis has sent me instructions on how to look at ui on the machine via RDP. > I'll try that, haven't been able to get that to work yet. Let me know what I can do to help. I can send you a screenshot of Putty if need be. So I ran these tests today and have access to the hudson machine to watch them. However, I can't see any Eclipse UI appear on the Hudson machine when the tests are running. So my next step is to run an eclipse installation on that hudson slave via remote desktop and see if the same issue occurs. If not, we know it's an issue with running the tests within Hudson. If Hudson was started as a service (Matt: was it?) I doubt you'll get to see its UI. Perhaps Hudson should be started from an RDP connection as the hudsonbuild user. (In reply to comment #26) > If Hudson was started as a service (Matt: was it?) I doubt you'll get to see > its UI. Yes it was/is. -M. Matt, is Kim's tests still fail, can we start the Hudson slave from the commandline of the hudsonbuild user to see if that makes a difference? It's not the hudson ui that's the problem. It's that the Eclipse ui that's not appearing. I'm trying some things, will let you know what happens. Presumably, eclipse is launched bu Hudson. Since Hudson is launched as a service, it likely doesn't have a graphical shell that it can send display to. If Hudson was launched from a command prompt as a logged-in user, then it can use the parent display. Okay, feel free to change it and I can run the tests and see if it works :-) Ok, I've stopped the running service and started the slave process by hand in a dos window. -M. Thanks Matt, this did the trick! The SWT tests all passed. Still having issues with jface tests, will ask the UI to investigate further. https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/JUnit-win/183/testReport/ Is the windows slave configured so that Hudson will start this way upon reboot? This is great news. So the moral of the story is that, on Windows, to run UI tests on Husdon the Hudson slave cannot be started as a service.
> Is the windows slave configured so that Hudson will start this way upon reboot?
AUTOEXEC.BAT !!
I'm keeping that option in reserve. I've added a task to Windows to 'start' the slave when the Hudson user logs in(and disabled the service startup). So the next time we restart things we should just have to login and the slave should start, if that fails then I'll bring out the autoexec hammer. -M. (In reply to comment #34) > This is great news. So the moral of the story is that, on Windows, to run UI > tests on Husdon the Hudson slave cannot be started as a service. > > > Is the windows slave configured so that Hudson will start this way upon reboot? > > AUTOEXEC.BAT !! Why can't you give the Hudson service access to the UI, by configuring the service entry to allow interaction with the UI? > Why can't you give the Hudson service access to the UI, by configuring the
> service entry to allow interaction with the UI?
Don't make the mistake of assuming we know how to do stuff with Windows. I didn't know you could do that.
|