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
