This is a placeholder for my finding.
I will try to investigate the difference between RVM and rbenv first
and letting (1) be second priority.
Apparently issue 1 does not occur when using childprocess 0.2.3 and using git bisect shows that jarib/childprocess@5488ed4 is the offending commit.
I have fixed (1) by updating to adopt the new behaviour in ChildProcess (this is done in #129). When investigating (2), i.e. why it passed using rbenv, I couldn't reproduce it... Anyway now all the tests passes using MRI via both rbenv and RVM
Left is only a couple of cucumber test (using jruby) that fails... I will investigate on this... But I can't see in (travis build) history that cukes has ever passed using jruby. So I suggest that this is disabled in the jruby on Travis until it has been fixed:
Anyway I can't see how we are going to fix issues like the ones seen on Travis:
$ bundle install
Fetching gem metadata from http://rubygems.org/.........
Installing rake (0.9.2.2)
Installing ffi (1.1.5)
Installing childprocess (0.3.5)
Installing builder (3.1.3)
Installing diff-lcs (1.1.3)
Installing json (1.7.5)
Installing gherkin (2.11.4)
Installing cucumber (1.2.1)
Installing rspec-expectations (2.11.3)
Using aruba (0.5.0) from source at /home/travis/builds/cucumber/aruba
Installing rack (1.4.1)
Installing bcat (0.6.2)
Installing rdiscount (1.6.8) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
WARNING: JRuby does not support native extensions or the `mkmf' library very well.
Check http://kenai.com/projects/jruby/pages/Home for alternatives.
mkmf.rb can't find header files for ruby at /home/travis/.rvm/rubies/jruby-1.6.8-d19/lib/native/include/ruby/ruby.h
Gem files will remain installed in /home/travis/.rvm/gems/jruby-1.6.8-d19/gems/rdiscount-1.6.8 for inspection.
Results logged to /home/travis/.rvm/gems/jruby-1.6.8-d19/gems/rdiscount-1.6.8/ext/gem_make.out
An error occured while installing rdiscount (1.6.8), and Bundler cannot continue.
Make sure that `gem install rdiscount -v '1.6.8'` succeeds before bundling.
install: 'bundle install' returned false.
So we should probably stick to MRI versions of ruby for now...
I have marked all scenarios not working (yet) with jruby with @wip-jrupy, and locally everything works fine using bundle exec rake test even using jruby (both via RVM and rbenv). However on Travis there seems to be installiblity problems with jruby, see https://travis-ci.org/#!/cucumber/aruba/jobs/2773121
bundle exec rake test
On jruby in 1.9 mode there are still problems with the rdiscount gem, see https://travis-ci.org/#!/cucumber/aruba/jobs/2773122
Now I have updated the .travis.yml to exclude jruby 1.9 mode for now...
Everything should be fine now... But apparently jruby runs differently on Travis than on my computer...
OK. I can reproduce the java.lang.ThreadDeath thrown from problem with java 7 (which is used by Travis). I will investigate...
java.lang.ThreadDeath thrown from
Awesome work @jarl-dk!
This status is made at this point in time
The following versions works without any errors
For jruby I have investigated the following combinations
The boldface is the combination used on Travis.
I have examined that status of the build by running these two commands
bundle exec rake
The default rake task both runs all the working scenarios, but also the WIP scenarious in wip mode.
On both rbenv and RVM the behaviour is consistent: failing all the scenarios that are marked @wip or @wip-jruby, and passing all others.
On jruby-1.7.0-rc2 (both rbenv and RVM) it is necessary to compile as
JRUBY_OPTS='-Xcext.enabled=true' bundle update
This is the combination used by Travis.
Apparantly this combination seem not very stable. All the spec tests
run fine, but it fails sporadically on scenarios that are not marked
@wip or @wip-jruby. Failures includes failures like
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Thread-2"
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Th
To resolve the problems (on Travis) I will investigate the consistent
failures on the combinations java 6, jruby-1.6.8 and java 7,
jruby-1.7.0-rc2. It is much easier to resolve consistent errors than
trying to resolve sporadic errors. That may or may not resolve the
problems on java 7, jruby-1.6.8.
I suggest that you merge this PR (#129) now. And I will continue to investigate the jruby issues.
I think we should disable jruby builds from Travis. We need this PR: jarib/childprocess#40 on childprocess to make them work... But that is not enough... There is also an issue in jruby itself... This valid shell line
bundle exec bash -c '(sleep 0; echo "Hello") | ruby -e "puts gets"'
works fine on any MRI ruby and should also work fine on jruby but jruby prints nil. However the almost identical line
bundle exec bash -c '(sleep 4; echo "Hello") | ruby -e "puts gets"'
works fine (though quite slow) on jruby
To work around that jruby bug (or odd behaviour) I will rewrite the aruba tests to use less ruby commands for the interactive tests, but cat...
I have filed a bug report on the JRuby project about the above described problem.
1) Almost all tests are dependant on childprocess to contain this Pull Request:
2) Two cukes ("Running ruby interactively" and "Tons of interactive output" additionally requires either this Pull Request in childprocess jarib/childprocess#40. The PR is merely a workaround for this
bug which should be fixed in jruby 1.7.1
3) Still even if both of those childprocess pull requests are used, still it sometimes happen that the "Running ruby interactively" fails with an exception like this:
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread \"Thread-2
It may be because of this bug in JRuby. It has only been seen on a cross between jruby 1.6.8 and JAVA 7.
I consider this to be done now, the Travis failures is commented in #129 (comment)
Any comments? @mattwynne ?
So travis is happy with #129. Closing this one.
this sounds somehow familiar to me, see http://jira.codehaus.org/browse/JRUBY-6162
Charles Nutter tried to fix it for 1.7, but moved it to 1.7.1
I also see messages like
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Thread-47"
in various cases but only with JRuby 1.6.8. Wiht 220.127.116.11 I've never seen them.
They fixed the JRuby bug we found in #130
So we can remove the WIP tag
Revert "They fixed the JRuby bug we found in #130"
This reverts commit be6479c.
Maybe they didn't...? The scenario has failed on JRuby this time. No
time to fix it now so going back to where we were before.