Windows JRuby 64-bit Issues #26

mitchellh · 2012-01-19T18:00:57Z

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?

The text was updated successfully, but these errors were encountered:

mitchellh · 2012-01-19T18:16:01Z

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

jarib · 2012-01-19T18:20:53Z

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

jarib · 2012-01-23T09:39:46Z

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.

jarib · 2012-01-23T10:10:15Z

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

jarib · 2012-01-27T10:14:13Z

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>

denderello · 2012-01-31T13:03:50Z

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

jarib · 2012-01-31T13:12:32Z

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.

mitchellh · 2012-01-31T18:16:02Z

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

dankilman · 2013-03-14T15:54:26Z

Hi there, has this issue been forgotten?

jarib · 2013-03-14T16:00:16Z

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

dankilman · 2013-03-17T00:32:37Z

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

JRuby implements IO.pipe using java.nio.channels.Pipe
The underlying implementation (in windows at least) uses java.nio.channels.SocketChannel(s)
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.

jarib · 2013-03-17T01:07:16Z

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

dankilman · 2013-03-17T08:01:22Z

Thanks. This seem to do the trick for now.

mitchellh · 2014-01-17T05:46:08Z

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 · 2014-03-15T11:36:58Z

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.

Zapotek · 2015-03-11T23:21:47Z

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

sds · 2019-01-12T06:11:06Z

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

This was referenced Jan 19, 2012

Windows JRuby 64-bit Issues #27

Closed

Windows JRuby 64-bit Issues #28

Closed

jarib mentioned this issue Feb 5, 2012

Inconsistent IO on JRuby #30

Closed

jarib mentioned this issue Feb 23, 2015

Unknown error in child-process gem when trying to open phantomjs browser in webdriver when running on jruby jruby/jruby#2598

Closed

sds closed this as completed Jan 12, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows JRuby 64-bit Issues #26

Windows JRuby 64-bit Issues #26

mitchellh commented Jan 19, 2012

mitchellh commented Jan 19, 2012

jarib commented Jan 19, 2012

jarib commented Jan 23, 2012

jarib commented Jan 23, 2012

jarib commented Jan 27, 2012

denderello commented Jan 31, 2012

jarib commented Jan 31, 2012

mitchellh commented Jan 31, 2012

dankilman commented Mar 14, 2013

jarib commented Mar 14, 2013

dankilman commented Mar 17, 2013

jarib commented Mar 17, 2013

dankilman commented Mar 17, 2013

mitchellh commented Jan 17, 2014

kamazee commented Mar 15, 2014

Zapotek commented Mar 11, 2015

sds commented Jan 12, 2019

Windows JRuby 64-bit Issues #26

Windows JRuby 64-bit Issues #26

Comments

mitchellh commented Jan 19, 2012

mitchellh commented Jan 19, 2012

jarib commented Jan 19, 2012

jarib commented Jan 23, 2012

jarib commented Jan 23, 2012

jarib commented Jan 27, 2012

denderello commented Jan 31, 2012

jarib commented Jan 31, 2012

mitchellh commented Jan 31, 2012

dankilman commented Mar 14, 2013

jarib commented Mar 14, 2013

dankilman commented Mar 17, 2013

jarib commented Mar 17, 2013

dankilman commented Mar 17, 2013

mitchellh commented Jan 17, 2014

kamazee commented Mar 15, 2014

Zapotek commented Mar 11, 2015

sds commented Jan 12, 2019