495533 - upgrade Windows reference platform to include Java SE 6 Update 14

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Josh Aas]

https://wiki.mozilla.org/ReferencePlatforms/Win32#Java

According to this our Windows reference platform has Java SE 6 Update 10 installed. This is actually used by our tests since we have tests that use the applet tag.

Java SE 6 Update 10 includes an NPAPI-based Java plugin, but that Java plugin still uses XPCOM for some things like cookie handling. Java SE 6 Update 14 removes all XPCOM dependencies.

Gecko 1.9.2 will not include support for any parts of the XPCOM plugin API, which means that Java SE 6 Update 14 will be the minimum version of Java for Gecko 1.9.2.

We need to upgrade the Windows reference platform so that we can remove all support for the XPCOM plugin API on trunk without breaking tests. We'd like to do this early in the 1.9.2 development cycle which will require all trunk tinderboxes to be upgraded.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

These machines are all shared between Gecko 1.9.1, 1.9.2 and any project branches (like TraceMonkey). Would you need the Gecko 1.9.1 tests to continue to use the existing Java install ? (Please say no)

At any rate, there enough windows slaves now that this will depend on bug 474572.

Comment 2

[Josh Aas]

No, as far as I know nothing needs to stay on the existing Java install.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Josh: can you test 1.9.1, before we make such an upgrade?  As far as we know, nothing is ever wrong with our patches, but testing makes a lot of sense nonetheless!

Comment 4

[Josh Aas]

I have tested Firefox 3.0.10 and the current Firefox 3.5 nightly, both work fine with Java SE 6 Update 14.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Can we get a timeline when this needs to be in effect by?  We'll discuss at RelEng meeting to assign it.

Comment 6

[Josh Aas]

I have a patch about ready to go, I'd be able to push a week from now (assuming the trunk is open). I'm guessing the RelEng schedule is pretty hectic right now, any chance we could do this within 3-4 weeks? If I had to wait longer it wouldn't be the end of the world, but the sooner I get going on this big project to clean up our plugin module the better, and I can't get too far until this is done.

Comment 7

[[e-mail] (:bhearsum)]

Attachment: OPSI package for installing the JDK

Here's an OPSI package for installing the JDK. Pretty straightforward - the only complication is that the jdk package requires a different "shut up" option than the jre. The two installers will be checked into the opsi-binaries area of mofo.

OPSI isn't yet on the production systems so this won't speed up deployment, but it's a good test for OPSI in staging.

Comment 8

[[e-mail] (:bhearsum)]

Comment on attachment 381063 [details] [diff] [review]
OPSI package for installing the JDK

changeset:   8:7ea1b984bd58

Comment 9

[[e-mail] (:bhearsum)]

Comment on attachment 381063 [details] [diff] [review]
OPSI package for installing the JDK

Checking in jdk-6u14-windows-i586.exe;
/mofo/opsi-binaries/java/jdk-6u14-windows-i586.exe,v  <--  jdk-6u14-windows-i586.exe
initial revision: 1.1
done
RCS file: /mofo/opsi-binaries/java/jre-6u14-windows-i586.exe,v
done
Checking in jre-6u14-windows-i586.exe;
/mofo/opsi-binaries/java/jre-6u14-windows-i586.exe,v  <--  jre-6u14-windows-i586.exe
initial revision: 1.1
done

Comment 10

[[e-mail] (:bhearsum)]

Lukas and I just upgraded the staging slaves (03, 04, 21) with the OPSI package.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Bump Java version in xulrunner mozconfigs

Comment 12

[[e-mail] (:bhearsum)]

Comment on attachment 381304 [details] [diff] [review]
Bump Java version in xulrunner mozconfigs

I don't think we use them, but for completeness please bump the tracemonkey/xulrunner/mozconfig paths, too.

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Bump Java version in xulrunner mozconfigs

adds tracemonkey changes.

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: OPSI package for installing the JDK with removal of old JDK

This was tested successfully on staging-opsi, it correctly installs 1.6.0_14 and removes 1.5.0_10

Comment 15

[[e-mail] (:bhearsum)]

Comment on attachment 381357 [details] [diff] [review]
OPSI package for installing the JDK with removal of old JDK

Looks good to me!

Comment 16

[[e-mail] (:bhearsum)]

Comment on attachment 381357 [details] [diff] [review]
OPSI package for installing the JDK with removal of old JDK

changeset:   9:05056b0a05cc

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

We're going to wait and roll this out when we put OPSI into place on our windows builders.

Comment 18

[[e-mail] (:bhearsum)]

We did a bunch of the slaves today: moz2-win32-slave01 -> 21 and 23 -> 29. That only leaves slave22, and the try slaves.

I'll get slave22 when it becomes idle, and we'll do the try slaves tomorrow.

Comment 19

[[e-mail] (:bhearsum)]

(In reply to comment #18)
> I'll get slave22 when it becomes idle

slave22 is done now.

Comment 20

[[e-mail] (:bhearsum)]

So, this caused a permanent orange state due to a leak from some of the test_HTMLBodyDocument* tests, which is bug 471647. If I remove the Java plugin and run the tests again there is no leak.

I don't know if this is a leak that is simply tripped by the new Java, or if the leak is within Java itself. I'm going to put together a patch to enable a leak threshold for windows to get rid of the orange. If desired, I could also backout Java until this is fixed.

Comment 21

[Josh Aas]

If we can disable that test for now and file a bug on it being disabled I'll take responsibility for resolving it as soon as I can. I really don't want to roll back the Update 14 installation.

Comment 22

[[e-mail] (:bhearsum)]

(In reply to comment #21)
> If we can disable that test for now and file a bug on it being disabled I'll
> take responsibility for resolving it as soon as I can. I really don't want to
> roll back the Update 14 installation.

I'm about to post a patch that will set a leak threshold for mochitest - that should get us green again. Probably better to run the tests and ignore the leak for now than not to run them at all.

Comment 23

[Josh Aas]

(In reply to comment #22)
> I'm about to post a patch that will set a leak threshold for mochitest - that
> should get us green again. Probably better to run the tests and ignore the leak
> for now than not to run them at all.

Sounds good. Please leave a bug open and assign it to me so I can investigate the leak. Thanks!

Comment 24

[[e-mail] (:bhearsum)]

Attachment: set a leak threshold of 484 bytes for mochitest

This patch sets a leak threshold of 484 bytes for the mochitest-plain target. I've dug through most of the runs post-java landing and AFAICT the leak is consistently 484. This patch should get us green again.

Comment 25

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 382450 [details] [diff] [review]
set a leak threshold of 484 bytes for mochitest

Looks good, r+

Comment 26

[[e-mail] (:bhearsum)]

Comment on attachment 382450 [details] [diff] [review]
set a leak threshold of 484 bytes for mochitest

changeset:   1183:255fec2e864d

Comment 27

[Nick Thomas [:nthomas] (UTC+12)]

We're leaking 484 bytes during crashtest too, but don't have the code in place to quickly pass a leakThreshold to buildbotcustom.steps.unittest.MozillaReftest. Doesn't look at all hard, just short of time to do it right now.

Comment 28

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Fix path to jdk

The win32 xulrunner builds died out with
/e/builds/moz2_slave/mozilla-central-win32-xulrunner/build/configure: cd: /d/jdk1.5.0_10: No such file or directory
configure: error: The header jni.h was not found.  Set $JAVA_HOME to your java sdk directory, use --with-java-bin-path={java-bin-dir}, or reconfigure with --disable-javaxpcom.
make[1]: *** [configure] Error 1
make: *** [obj-firefox/Makefile] Error 2

This patch corrects the path in the mozconfigs, and gets through configure. It looks like we really had Java 5 Update 10 installed rather than Java 6 Update 10.

Comment 29

[Serge Gautherie (:sgautherie)]

(In reply to comment #27)
> We're leaking 484 bytes during crashtest too, but don't have the code in place
> to quickly pass a leakThreshold to
> buildbotcustom.steps.unittest.MozillaReftest.

This would be bug 460548.

Comment 30

[[e-mail] (:bhearsum)]

Comment on attachment 382474 [details] [diff] [review]
Fix path to jdk

This is the same patch that lukas posted that we helpfully didn't land when we installed java :(

Comment 31

[[e-mail] (:bhearsum)]

Comment on attachment 381317 [details] [diff] [review]
Bump Java version in xulrunner mozconfigs

I landed this and kicked new xr builds
changeset:   1188:3c1e7de4ceda

Comment 32

[[e-mail] (:bhearsum)]

(In reply to comment #27)
> We're leaking 484 bytes during crashtest too, but don't have the code in place
> to quickly pass a leakThreshold to
> buildbotcustom.steps.unittest.MozillaReftest. Doesn't look at all hard, just
> short of time to do it right now.

I'm working on a patch to do this.

Comment 33

[[e-mail] (:bhearsum)]

Attachment: set crashtest leak threshold to 484

Comment 34

[[e-mail] (:bhearsum)]

Attachment: allow for crashtest leak threshold to be passed

This patch also fixes the PackagedUnittestFactory to only pass the mochitest_leak_threshold to mochitest-plain - as is the case in UnittestBuildFactory.

Comment 35

[[e-mail] (:bhearsum)]

Comment on attachment 382516 [details] [diff] [review]
allow for crashtest leak threshold to be passed

changeset:   329:453f0bbda966

Comment 36

[[e-mail] (:bhearsum)]

Comment on attachment 382515 [details] [diff] [review]
set crashtest leak threshold to 484

changeset:   1192:5cee911de535

Comment 37

[[e-mail] (:bhearsum)]

Attachment: same threshold for try

Comment 38

[[e-mail] (:bhearsum)]

Comment on attachment 382970 [details] [diff] [review]
same threshold for try

changeset:   1196:61ebbaba77ea

Comment 39

[[e-mail] (:bhearsum)]

try slaves have been upgraded. only thing left is the ref platform, which will get done on monday.

Comment 40

[[e-mail] (:bhearsum)]

The ref platform VM has been updated now. I think we're all done here.

Comment 41

[Serge Gautherie (:sgautherie)]

You can now remove the threshold for "trunk" builds: see bug 471647 comment 19.