Bugzilla – Full Text Bug Listing
| Summary: | switch to testing 64bit mac sdks | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Moir <kim.moir> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | david_williams, markus.kell.r, ob1.eclipse |
| Version: | 3.8 | ||
| Target Milestone: | 4.2.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 340991 | ||
| Bug Blocks: | |||
|
Description
Kim Moir
I think this was done in Juno as part of move to eclipse.org hudson testing. David can you confirm if we are testing the 64-bit mac build on Hudson? no, 32-bit still, from a quick glance. I honestly do not know what the machine is capable of but can investigate once we get going again. I've not had time to look at this, and seems a bad time to change anything ... unless I learn something that "all is ready", or something. To cross reference, if/when work is needed, see bug 388285. I have confirmed we are (still) currently using 32 bit one, and think bug 340991 will be updated when 64 bit one is provisioned. Status: Now that bug 340991 has been fixed, I started to explore running our tests on this 64 bit machine (with 64 bit VM and 64 bit Eclipse, of course). The first issue was the same problem as encountered running "new VMs" and XSLT ant task (bug 390494). I worked around that using the "ext dir" solution as documented in bug 390494. One difference, in my Windows experiments, I used the "whole" xalan package serializer.jar xalan.jar xercesImpl.jar xml-apis.jar But, when I did that on the Mac, there were some immediate errors about not finding some Sax parser and it would fail immediately (long before doing anything XSLT related ... could not even read plugin.xml's). So, I tried just the main xalan jars, serializer.jar xalan.jar And that worked fine, to transform xml to html. The next problem encountered I've documented in bug 340991 comment 37. Some tests run fine, some fail completely. I think its a "core vs UI" issue, with lots of errors about _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. I'm hoping that's some simple "set up with Hudson" issue ... or else it might mean our app needs to be signed?! = = = = = Now, to be explicit, the original intent I believe was that we'd use this new machine to run all our max unit tests, and we no longer would run the 32 bit versions, right? I think one implication is that we still need to make sure there is another mac in the que, if/when we ever want to run mac performance tests. [The consensus being that the 32 bit mac is too old and too "small" to be useful? Right? Or am I imaging that?]. (In reply to comment #6) > Now, to be explicit, the original intent I believe was that we'd use this > new machine to run all our max unit tests, and we no longer would run the 32 > bit versions, right? Yes, that's correct. The background is that "in the wild" very few people use 32-bit versions on Mac in this day and age. Plus there are small differences in how things behave on 32-bit vs 64-bit machines, so it makes sense to test on what consumers actually use. > > I think one implication is that we still need to make sure there is another > mac in the que, if/when we ever want to run mac performance tests. [The > consensus being that the 32 bit mac is too old and too "small" to be useful? > Right? Or am I imaging that?]. It is more that 32-bit is no longer widely used, so there is always a question of whether the Mac issues we see in tests are generic or are specific to 32-bit stack. That is especially important for performance tests. So it is not so much about being small (which is it not), but rather about being relevant. (In reply to comment #7) > (In reply to comment #6) > > Now, to be explicit, the original intent I believe was that we'd use this > > new machine to run all our max unit tests, and we no longer would run the 32 > > bit versions, right? > > Yes, that's correct. The background is that "in the wild" very few people > use 32-bit versions on Mac in this day and age. Plus there are small > differences in how things behave on 32-bit vs 64-bit machines, so it makes > sense to test on what consumers actually use. > > > > > I think one implication is that we still need to make sure there is another > > mac in the que, if/when we ever want to run mac performance tests. [The > > consensus being that the 32 bit mac is too old and too "small" to be useful? > > Right? Or am I imaging that?]. > > It is more that 32-bit is no longer widely used, so there is always a > question of whether the Mac issues we see in tests are generic or are > specific to 32-bit stack. That is especially important for performance > tests. So it is not so much about being small (which is it not), but rather > about being relevant. Thanks. To cross-reference, I made a comment in bug 389371 saying we could use another ... one for "normal" testing, and another for performance testing. [Others, feel free to comment there if you have other opinions/priorities and/or requirements for a Mac performance machine. I'd assume it'd be about the same as for those documented in bug 340991]. 2 steps forward, one step back. With Eclipse Foundations help, the new Mac is already to go and I think working right for our tests (working well, even). I used it for last night's N build, but the "summarizing" tools have some hard coded assumptions about "platform names" See bug 390986. I'll either quickly fix bug 390986 or revert the names being used back to be inaccurate. [Normally, I'd fix up files/summary "by hand", but won't have time until late today, and by then, would prefer to try and fix the real problem]. > I'll either quickly fix bug 390986 or revert the names being used back to be > inaccurate. Decided to be inaccurate. To correctly (and safely) re-compile the build.jar, I'd really have to move it up to Juno release (as that itself would be error prone, etc.) and I don't want to do that ... I'd rather work on getting it building separately, as its own plugin that could be added to generic SDK for building/testing. (bug 324682). I've switched over to using the 64 bit machine (and 64 bit VM and Eclipse) and it all seems to be working well. Definitely faster than the 32 bit version (which, could be related to several things, not just the "bits" but all in all, the unit tests complete here in about 5 hours (but remember that's missing 2 p2 tests that were DNFing all the time due to proxy issues). Eventually (in next week or two), I'll save the 32 bit Hudson job config.xml somewhere, then remove that job from Hudson ... that is, I am assume we will never need the 32 bit job again. Speak now or forever hold your peace. :) Just today remembered I had to create the ep3-unit-mac64 job to test 3.x stream. Its nearly identical to ep4-unit-mac64 we only have the two of them so we can "call" each to have in que (for some cases, we can run both type of tests at same time, such as linux can go to different slaves). BUT, whole point ... I double checked equinoxp2tests.properties, not recalling if I'd defined/changed yet. Specifically /org.eclipse.releng/configuration/eclipseBuilderOverlays/eclipse/buildConfigs/sdk.tests/testConfigs/macosx/equinoxp2tests.properties I had created and had added/changed org.eclipse.equinox.p2.reconciler.tests.lastrelease.platform.archive.macosx-x86_64 But noticed that this variable: org.eclipse.equinox.p2.reconciler.tests.platform.archive.macosx still pointed to 32 bit version, even in master. So ... not sure if its not used? Or ... if something hasn't been testing right because of this. Just FYI ... making notes. |