Windows JRuby 64-bit Issues about childprocess HOT 17 CLOSED

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

from childprocess.

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
[email protected]:

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: hashicorp/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:
#26

from childprocess.

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.

from childprocess.

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

from childprocess.

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>

from childprocess.

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. :)

from childprocess.

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.

from childprocess.

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

from childprocess.

Hi there, has this issue been forgotten?

from childprocess.

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

from childprocess.

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.

from childprocess.

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).

from childprocess.

Thanks. This seem to do the trick for now.

from childprocess.

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.

from childprocess.

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:in assert_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.

from childprocess.

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

from childprocess.

Closing this due to age. Would welcome a pull request fixing the issue if it is still affecting people. Thanks!

from childprocess.