Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Windows JRuby 64-bit Issues #26

Open
mitchellh opened this Issue Jan 19, 2012 · 16 comments

Comments

Projects
None yet
6 participants
Contributor

mitchellh commented Jan 19, 2012

Hello hello,

Vagrant with JRuby on Windows 64-bit specifically has been seeing this error consistently:

ChildProcess::Error: Unknown error (Windows says "Operasjonen er utf\370rt.", but it did not.)
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:284
     windows_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/jruby.rb:48
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:265
  std_stream_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:135
               setup_io at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:105
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:29
         launch_process at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process.rb:62
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/abstract_process.rb:62
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:56
                  chdir at org/jruby/RubyDir.java:335
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:55
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:20
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:279
                   busy at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/busy.rb:19
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:278
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:254
           read_version at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:117
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:36
                reload! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:129
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:35
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:426
                   each at org/jruby/RubyArray.java:1603
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:425
                    vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:114
               multivm? at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:147
            vms_ordered at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:122
        with_target_vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/base.rb:88
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/up.rb:39
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/cli.rb:38
                    cli at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:156
                 (root) at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/bin/vagrant:43
                   load at org/jruby/RubyKernel.java:1063
                 (root) at c:\jruby-1.6.4\bin\vagrant:19

See: mitchellh/vagrant#654

Note that the above user seems to have an international machine, but this happens on American machines as well, with the translation being "The operation completed successfully." but apparently did not?

This was referenced Jan 19, 2012

Contributor

mitchellh commented Jan 19, 2012

Looks like GitHub was having issues when I submitted this, since it made 3. :) Closed the duplicates. This is the real deal.

Collaborator

jarib commented Jan 19, 2012

I'll look closer at this tomorrow, but for now try upgrading JRuby to

= 1.6.5 and see if that helps. Otherwise this can proably be worked
around by downgrading childprocess to 0.2.8.

I'll join #vagrant tomorrow as well :)

Den 19. jan. 2012 kl. 19:00 skrev Mitchell Hashimoto
reply@reply.github.com:

Hello hello,

Vagrant with JRuby on Windows 64-bit specifically has been seeing this error consistently:

ChildProcess::Error: Unknown error (Windows says "Operasjonen er utf\370rt.", but it did not.)
            handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:284
    windows_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/jruby.rb:48
            handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:265
 std_stream_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:135
              setup_io at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:105
                 start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:29
        launch_process at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process.rb:62
                 start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/abstract_process.rb:62
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:56
                 chdir at org/jruby/RubyDir.java:335
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:55
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:20
                   raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:279
                  busy at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/busy.rb:19
                   raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:278
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:254
          read_version at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:117
            initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:36
               reload! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:129
            initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:35
             load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:426
                  each at org/jruby/RubyArray.java:1603
             load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:425
                   vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:114
              multivm? at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:147
           vms_ordered at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:122
       with_target_vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/base.rb:88
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/up.rb:39
               execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/cli.rb:38
                   cli at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:156
                (root) at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/bin/vagrant:43
                  load at org/jruby/RubyKernel.java:1063
                (root) at c:\jruby-1.6.4\bin\vagrant:19

See: mitchellh/vagrant#654

Note that the above user seems to have an international machine, but this happens on American machines as well, with the translation being "The operation completed successfully." but apparently did not?


Reply to this email directly or view it on GitHub:
jarib#26

Collaborator

jarib commented Jan 23, 2012

Ugh, it seems the cause here is something similar to this: _get_osfhandle returns -1 for an fd that seems to be valid. Still looking into it.

I also messed up with the spec filters, which is why I didn't catch this before releasing. Fixed that in 0e6b1ea.

Collaborator

jarib commented Jan 23, 2012

And this only fails when using IO.pipe with JRuby on Windows.

Collaborator

jarib commented Jan 27, 2012

I was hoping the switch to the FFI implementation on Windows was a good first step in getting rid of the JRuby-specific code in this gem. If I can't figure out how to get the native fds, we should probably roll back to the old java.lang.ProcessBuilder implementation and the IO pump threads - especially if this is affecting a lot of Vagrant users who want to use JRuby on Windows.

Unless of course @headius or @enebo has some ideas? Here's the reduced problem:

Z:\git\childprocess>jruby -S irb -I lib -r childprocess
irb(main):001:0> r,w = IO.pipe
=> [#<IO:0x13c53a8>, #<IO:0x1984a9d>]
irb(main):002:0> fileno = JRuby.reference(r).channel.getFDVal
=> 424
irb(main):003:0> ChildProcess::Windows::Lib.get_osfhandle(fileno)
=> -1
irb(main):004:0>

Would be really nice to have this fixed. This issue prevents us from updating to a newer Vagrant version right now which finally makes some feature usable on Windows. :)

Collaborator

jarib commented Jan 31, 2012

Absolutely would like to get this fixed. But this probably won't be stable if we roll back to ProcessBuilder either:

https://github.com/jarib/childprocess/blob/master/spec/io_spec.rb#L81

The best solution would be to find some way to get the native fd.

Contributor

mitchellh commented Jan 31, 2012

@denderello If you use RubyInstaller with 1.9.3 then Vagrant works swimmingly. I want the JRuby issues fixed too though :(

Hi there, has this issue been forgotten?

Collaborator

jarib commented Mar 14, 2013

Not forgotten, I just have no idea how to solve it. Feel free to dig in to see if you can figure it out.

I've done some research and this is what I've come up with so far:

  1. JRuby implements IO.pipe using java.nio.channels.Pipe
  2. The underlying implementation (in windows at least) uses java.nio.channels.SocketChannel(s)
  3. When you call channel.getFDVal in windows you get the descriptor for the socket which from what I learned is mapped to WINSOCK which is not part of the file system (so get_osfhandle will always return -1).
    http://stackoverflow.com/questions/4676256/whats-the-difference-between-socket-and-handle-in-windows
    http://elliotth.blogspot.co.il/2005/08/javaiofiledescriptor-on-win32.html

I'm not really sure if this helps much but this is what I could come up with for now.
In the comments above, you mentioned that using ProcessBuilder was not a good solution either. What were the issues there?

BTW: I come from a Java background and have almost zero ruby knowledge/experience.
My interest in resolving this issue is to use vagrant in java using https://github.com/guigarage/vagrant-binding.

Collaborator

jarib commented Mar 17, 2013

Thanks for looking. The info about WINSOCK not being part of the file system is interesting and worth looking in to, but IIRC this is exactly where gave up the last time I tried (the FFI code is already special cased to avoid get_osfhandle on JRuby).

With ProcessBuilder I also had issues with pipes, which is why this spec is disabled (that's what I was trying to link to in my earlier comment). However we've since seen some patches in this area, so the situation may have improved.

In any case I should make it so that JRuby+Windows users can choose between the FFI and the ProcessBuilder implementation. I'll have access to a Windows machine next week and hope to find some time to look into this then. If you want to try it out immediately, you could hack your Vagrant installation and replace the call to ChildProcess.build(*args) with ChildProcess::JRuby::Process.new(args).

Thanks. This seem to do the trick for now.

Contributor

mitchellh commented Jan 17, 2014

2 years later, I have to add to this:

This error can also arise if you give Windows CreateProcess a path to an application that doesn't exist or is invalid. Example: ChildProcess.build("C:\lol").start raises this error too.

More subtly, this becomes an issue in the various shells of Windows, since CreateProcess can only launch Windows executables (naturally). So, if you have a bash script foo, that is certainly executable within Cygwin, but if you do ChildProcess.build("foo").start, you'll get this exception.

So, if you're on Windows, you have to mindful to properly prepare paths so that they can be executed with CreateProcess.

kamazee commented Mar 15, 2014

I've just faced [possibly] the same issue and have one more thing to add to what @mitchellh said.

The path must be not just existing, but also executable (which is not really clear in Windows environment). Calling a non-executable produces an error which does not really nail the issue (something like C:/Users/Alex/software/vagrant/embedded/gems/gems/childprocess-0.5.1/lib/childprocess/abstract_process.rb:183:inassert_started': process not started (ChildProcess::Error)-- for a non-executable .bat that run perfectly from wincmd). Making it executable (chmod +x` in cygwin or just a corresponding tick at file's properties window) fixed the issue.

Just in case: I've hit it while trying to run ansible as vagrant provisioner in Windows.

Zapotek commented Mar 11, 2015

This issue re-appeared with JRuby 9.0.0.0pre1, getting the same error and ChildProcess::JRuby::Process doesn't seem to work either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment