More... * The intermittent Fiber failure in the 1.9 RubySpec build were my fault. I did not take enough care to make sure rogue fibers could not wake up threads at random. I committed a new version that uses Exchanger and it appears to consistently pass all specs. I still need to investigate if it impacts performance.
* There are two encoding specs that only fail on Java 5. It appears that Java 5's CharsetEncoder is happily allowing invalid EUC_JP input to be transcoded to ISO-8859-1 while Java 6 disallows it with an error. Since the CharsetEncoder is set to REPORT on errors, I must assume this is a bug. I'm introducing a new tag, "java1.5" that we can use to mask out this and other specs. It will be applied automatically when running on a particular version of Java. With these fixes, the interpreted 1.9 spec run is green, and "speci-ci" is finally green again after months of being red. Hooray! The next target was to get jruby-test-all-release green, since it failed last night. I modified test/test_timeout.rb's net/http timeout test to use a server that appears to ignore port 80, one of the Google open DNS servers, 8.8.8.8. That appeared to make the test quicker and more reliable on my machine, so I pushed it. I have not yet run a jruby-test-all-release CI run yet to test it. Tomorrow I will hopefully finally get to the cross-JVM builds. - Charlie On Tue, Dec 6, 2011 at 3:07 AM, Charles Oliver Nutter <head...@headius.com> wrote: > And yet more... > > * Modified the mspec runs to pass "-T -J-XX:MaxPermSize=512M" instead > of trying to set JAVA_OPTS all over. It seems that mspec must do some > env scrubbing, or something...so telling it to explicitly pass a -J > argument to the child JRuby process seems to have worked. The > interpreted, compiled (JIT), and precompiled (forced JIT) 1.8 spec > runs are all green again. > > * The 1.9 spec runs appear to fail with varying numbers of failures. > That's going to take more time to investigate. The fiber specs in > particular seem to pass sometimes and fail sometimes. > > * I've started making an attempt to get the Windows builds green > again. They seem to have decayed to the point of not actually even > starting up ant right, which could be due to my other changes. I added > an explicit path to ant's home and an ANT_HOME env var, and they're at > least attempting to build again. They are still failing, however; we > need to sit down with a Windows box and get everything green there. > > * I kicked off the cross-JVM matrix, and it appears that JRockit fails > because we're using nonstandard flags (CMS stuff, it appears) and J9 > fails (both versions) due to actual test failures. Will require a bit > more work. sun-java-5 and sun-java-6 are both green again. > > - Charlie > > On Tue, Dec 6, 2011 at 1:20 AM, Charles Oliver Nutter > <head...@headius.com> wrote: >> Additional tweaks... >> >> * There's a difference in File.flock behavior between Java 5 and later >> versions. Specifically, on later versions you have to have the file >> open in specific modes (read/write) to be able to do shared and >> exclusive locks. There's a guard in RubySpec for this behavior, which >> is exhibited on OpenJDK 6 and later and *should* be exhibited on any >> version of MRI on Solaris (which is the lowest-common-denominator >> excuse for the Java behavior). Because it only fails on Java 5 and the >> majority of users are on Java 6, I've added a Java 5-specific >> exclusion to spec/jruby.1.8.mspec and spec/jruby.1.9.mspec. That >> appears to be getting the spec runs green on Java 5...finally! >> >> * The spec runs were configured in Jenkins to have a maximum permgen >> of 128M, which caused my tweak from earlier to not take effect. I >> modified the Jenkins environment for spec-ci to allow permgen up to >> 512M. >> >> If I have time this evening (sick baby up late) I will attempt to get >> the cross-JVM build matrix green as well. We'll be greener than we've >> been in a long time, once that happens. >> >> - Charlie >> >> On Mon, Dec 5, 2011 at 11:30 PM, Charles Oliver Nutter >> <head...@headius.com> wrote: >>> Man, is this ever a painful job. >>> >>> I've spent most of the day trying to get CI builds green again, and >>> the server has been working against me. >>> >>> Most of the major builds were red...the spec builds, test-all, dist, >>> and I think jruby-base as well. In the process of fixing one build I >>> uncovered regressions in others, or uncovered bugs that caused more >>> builds to go red. Needless to say, I didn't expect to spend 15 hours >>> on this. >>> >>> I think I'm finally closing in on having everything green again, and >>> there were a few facts that came out of this I wanted to bring to >>> everyone's attention. >>> >>> * As I posted earlier, I added another test-all build for jruby-1_6. >>> It should help keep us honest. >>> >>> * Ant 1.7.0 is a pain in the ass. It appeared to ignore the JDK we >>> started it up with and always launched 'java' with whatever the >>> command on PATH was. BUT, it would run that JVM with the runtime you >>> started it up with...or something like that. In any case, those nasty >>> bizarre VerifyErrors came back. Ultimately I ended up going through >>> and explicitly making pretty much all builds use the ant182 install of >>> ant, *and* I modified Jenkins to puts that ant install at the front of >>> PATH. If I didn't do that, it seemed to keep picking up the >>> system-wide emerged "ant" and reverting to the old issues. >>> >>> * I had to bump up permgen on a couple of the precompiled tests again. >>> They're at 512M now. I also added permgen size to the spec runs, which >>> might cause them to break on JVMs that don't have a permgen flag. I'll >>> cross that bridge shortly. >>> >>> * I also forced almost all builds to run with Java 5. We've had some >>> bad Java 6 code sneak through again recently, and we need to keep the >>> builds honest across the board. All builds, unless otherwise >>> specified, will run with Java 5. >>> >>> I'm still in progress, but I'll write again in a while as more builds go >>> green. >>> >>> - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email