[WSL] Errno::ENOMEM

[ahorek]

originaly reported here rubygems/bundler#6700

I was able to reproduce the problem on a WSL https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
by running rails s command, it fails at this line
https://github.com/rails/rails/blob/5-2-1/railties/lib/rails/app_loader.rb#L53
there's a workaround jruby -S rails s

Script

exec Gem.ruby, '-v'

Environment

jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-09-28 8e6904f Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 +jit [linux-x86_64]

Linux DESKTOP-2POPPQP 4.4.0-17134-Microsoft #285-Microsoft Thu Aug 30 17:31:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
WSL 9.2.0.0 - fails
WSL 9.2.1.0 (master) - fails
WSL MRI 2.5.1 - works

free -h

             total       used       free     shared    buffers     cached
Mem:           15G       8,0G       7,9G        17M        33M       184M
-/+ buffers/cache:       7,8G       8,1G
Swap:          29G        47M        29G

Linux test 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 GNU/Linux
debian 9.2.0.0 - works
debian 9.2.1.0 (master) - works

Expected Behavior

exec Gem.ruby, '-v'

jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-09-28 8e6904f Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 +jit [linux-x86_64]

Actual Behavior

exec Gem.ruby, '-v'

Traceback (most recent call last):
        8: from /home/ahorek/.rvm/rubies/jruby-head/bin/irb:13:in `<main>'
        7: from org/jruby/RubyKernel.java:1178:in `catch'
        6: from org/jruby/RubyKernel.java:1178:in `catch'
        5: from org/jruby/RubyKernel.java:1412:in `loop'
        4: from org/jruby/RubyKernel.java:1040:in `eval'
        3: from (irb):7:in `evaluate'
        2: from uri:classloader:/jruby/kernel/kernel.rb:17:in `exec'
        1: from org/jruby/RubyKernel.java:1751:in `_exec_internal'
Errno::ENOMEM (Cannot allocate memory - No message available)

it's probably a WSL bug, but anyone has an idea where the actual problem is? how to debug it?

[ahorek]

extended trace

Traceback (most recent call last):
       16: from org/jruby/RubyKernel.java:1839:in `execCommon'
       15: from org/jruby/Ruby.java:3849:in `newErrnoFromLastPOSIXErrno'
       14: from org/jruby/Ruby.java:4236:in `newRaiseException'
       13: from org/jruby/exceptions/RaiseException.java:70:in `from'
       12: from org/jruby/RubyException.java:356:in `toThrowable'
       11: from org/jruby/RubySystemCallError.java:133:in `constructThrowable'
       10: from org/jruby/exceptions/SystemCallError.java:38:in `<init>'
        9: from org/jruby/exceptions/StandardError.java:38:in `<init>'
        8: from org/jruby/exceptions/Exception.java:38:in `<init>'
        7: from org/jruby/exceptions/RaiseException.java:60:in `<init>'
        6: from org/jruby/exceptions/RaiseException.java:94:in `preRaise'
        5: from org/jruby/exceptions/RaiseException.java:127:in `preRaise'
        4: from org/jruby/RubyException.java:388:in `prepareBacktrace'
        3: from org/jruby/runtime/backtrace/TraceType.java:44:in `getBacktrace'
        2: from org/jruby/runtime/backtrace/TraceType.java:243:in `getBacktraceData'
        1: from java/lang/Thread.java:1559:in `getStackTrace'
Errno::ENOMEM (Cannot allocate memory - No message available)

[kares]

seems like spawning out gets broken under WSL - being unable to allocate native memory ;( quite weird

[headius]

I do not have WSL handy at the moment but here's some thoughts on this...

On Windows normally, we will not use the native process launching logic, because it is not completely rigged up right for Windows APIs and expects more POSIXy environment.

Under WSL, I'm not sure what we do. I would think we detect the environment as Linux, which would make us go down the native path since our native exec logic is expected to work.

Or we might still go down the Windows path depending on how the platform queries.

So the reason this starts failing could be a bug introduced in the exec logic...or it could be that our detection of when to use the native logic has flipped one way or another in 9.2.1.

[headius]

@ahorek Got a few minutes to try to bisect this?

[ahorek]

Under WSL, I'm not sure what we do. I would think we detect the environment as Linux, which would > make us go down the native path since our native exec logic is expected to work.

WSL is recognized as Linux, so the native logic should be used.

it's definitely a WSL bug in the POSIX#execve function that jruby uses
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyKernel.java#L1822

simmilar issue microsoft/WSL#2959

it fails the same way even on jruby 1.7.20

workaround? #5352 also system() or `` works fine

this will probably be fixed some day in WSL itself, so feel free to close it.

[kares]

proposed work-around looks like it will attempt a sub-sequent exec for all -1 returns.
can it not break under some cases proper error handling?
maybe only run the 'work-around' on WSL, assuming there's a way to detect such env
... and even checking for error status ENOMEM explicitly.

[ahorek]

Right, +1 for checking ENOMEM explicitly.

WSL could be detected by uname.

[kares]

WSL could be detected by uname.

was hoping for smt lighter like system properties or ENV instead so we do not have to spawn to detect.
it also might be a good candidate to go into ... having Platform.IS_WSL

[ahorek]

done

[headius]

I merged in the related PR. Hopefully some day WSL will be fixed and this can go away.