io/console.rb on AIX not working in v9.x #3495
Comments
|
I am seeing the same issue on AIX (64bit JVM) using JRuby v9.0.4. Here is the full stack trace: Just as @ssteidte stated the cause of the failure is line 195 in io/console.rb: $stderr.dup throws an error (NotImplementedError: dup unsupported or native support failed to load) In the ensure block (line 202) the call $stderr.reopen(old_stderr) fails because old_stderr is nil, it was never set. I do not see this issue when using a 32bit JVM on AIX. |
|
Can one of you show me the result of booting JRuby with There's a couple possibilities:
Please also provide environment information, like |
|
the switch doesn't work: jruby -version: uname -a: |
|
sorry, didn't want to close it |
|
@ssteidte Sorry, if passing flags to |
|
still doesn't recognize the switch: |
|
|
|
|
@ssteidte -Djruby.native.verbose=true |
|
Oops, my mistake...@enebo is right, it's |
|
now this works :) Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows. |
|
uname -a: AIX f36smd1 1 7 00F646FB4C00 java --version:
|
|
@ssteidte Is that the complete output from I don't suppose there's any way to get shell access to an equivalent environment, so we can debug and test this in place? In the interim, my recommendation to you (if you have cycles to work with us) would be to start checking out JNR projects and see if they build and test successfully, starting with https://github.com/jnr/jffi and then moving on to jnr-ffi and jnr-posix. I suspect at least one of them will fail to run, which will give us something concrete to work on. |
|
FYI, all the JNR projects are straightforward maven projects; |
|
Yes, that was the whole output (I've just leaved out the Ruby part that is shown in the first post). |
|
Ok, well I'll stick with you until we can figure this out. I'm poking around for AIX cloud options now. Meanwhile... I think the general situation here is that our native support for AIX is failing to load, which in turn breaks a lot of things that expect to use native calls on *nix platforms. So he first thing to do is to figure out why it fails to load. I need from you:
If it's at all possible to try building jffi on AIX, that's going to be our fastest path forward. If you can stop by our IRC chat room today (http://chat.jruby.org) that would also help things along. |
|
If you decide you want to try the jffi build (requires Apache Maven, any recent version): ...and we can iterate from there. |
|
uname -a: java -version: jruby -rpp -e "pp RbConfig::CONFIG": gives the error that this is all about |
|
Anyone manage to get an AIX build of jffi working? Going to have to punt this since we don't really have a way to investigate it. We need your help. Note that fixes in jnr/jnr-enxio#12 may have improved this bug too, and it should be shipping with latest JRuby versions (1.7.25 and 9.1). |
|
I did the following: and got the following output: [INFO] Scanning for projects... main: -generate-version-source: main: |
|
Assuming jffi as culprit seems to be right. Tried the brand new version 9.1.3 and the error is now much later after the startup: |
|
If the error is much later than startup, I start to wonder if it's fixed but something unrelated is now broken. We have had some issues with flock not booting on platforms where fcntl is preferred for file-locking (like several non-Linux, non-BSD OSes) and have just added the function correctly or worked to reimplement it using appropriate calls (see jnr/jnr-posix#60, for example). So, if we can patch around this we may find things are working correctly. |
|
Link with #4112. |
|
update for JRuby 9.1.7: basically the same as in 9.1.3 NotImplementedError: flock unsupported or native support failed to load; see http://wiki.jruby.org/Native-Libraries |
|
Damn flock again! So is there no flock on AIX? It sounds like the FFI library is loading but it can't bind some things. This would be a situation similar to Solaris, where we must use fcntl to emulate flock. |
|
I seem to be running into this bug as well. The original "TypeError: no implicit conversion of nil into String", that is, I haven't made it as far as the flock issue yet. The comments above seem to suggest that an update to libjffi got past the original error message, but I'm still running into that error with JRuby 9.1.7.0. Is there some piece I'm missing that doesn't involve compiling jffi and friends from scratch? |
|
Although it's true that libjffi-1.2.a is broken on 64bit AIX and should be certainly be fixed, that may be tangential to the issue here. It turns out that libjffi was borked in JRuby 1.7 as well, yet the code I have triggering this error on 9k runs fine on 1.7. A simple require "io/console" on 1.7 will give a warning of "io/console not supported; tty will not be manipulated" but then the program continues to run. The relevant portion of console.rb is essentially the same in both versions of JRuby. The error shown at the start of this ticket is being triggered by $stderr.reopen but only because there is a rescue clause masking the previous error triggered by $stderr.dup a few lines earlier. Both of these methods appear to work in 1.7. Since this code is outside of any class definition it is run as soon as the require occurs which also makes it difficult to monkeypatch around it. Digging further down the rabbit hole takes us into RubyIO.java which is significantly different in 9k. At a glance I didn't spot any obvious reason why 1.7 has a working fallback and 9k doesn't, but I'm also probably in over my head at this point. So although a working libjffi would be ideal, it seems like JRuby 1.7 had enough of a fallback implementation to continue to work well enough (for some anyway) even in the absence of a working libjffi, while 9k does not. |
|
@iconoclast What are you running that produces the type error? The methods you say work fine in 1.7 are likely not dependent on native operations at all, preferring Java/JDK equivalents. So there's some platform exercise needed. It would be a lot easier to maintain AIX support if it were possible for us to run it locally and in CI 😢 I'll poke around and see if it's possible to do that today. |
|
@headius Reproducing this is as simple as requiring 'io/console'. As for how I'm using it in my project? Well I'm not actually using io/console directly in any of my own code but some of my gem dependencies do. From the traceback it would appear that Bundler is the first such gem to trip this. |
|
I have had little luck finding an AIX machine I can test against, so we're going to have to do some back-and-forth here. Run that again but pass |
|
No problem. Happy for the help. Well, -Xbacktrace.style=full just complained |
|
For access to AIX (and Linux on Power), check out the "IBM Power Development Cloud (PDP)": I'm told this is a way to get access to Power machines for debugging / testing. Caveat: I haven't tried it yet as my access request is pending. |
|
@headius any other info you need from this end that may be of help? |
|
I think we need to update this bug and see if it's still working with recent fixes and rebuilds of the AIX support. |
|
May be fixed in 9.2 with updated jffi AIX support. Need someone to confirm whether it still exists. Bumped to 9.2.1 in case it's still broken. |
|
No confirmation and good chance this is fixed with updated AIX support. Optimistically closing. |
On AIX, io/console.rb is broken for all versions of JRuby 9k including 9.0.4.
The error displayed is
TypeError: no implicit conversion of nil into String reopen at org/jruby/RubyIO.java:582 <top> at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/io/console.rb:202The reason is that the call $stderr.dup in line 195 fails:
NotImplementedError: dup unsupported or native support failed to loadThis error is caught, but the subsequent try to reopen old_stderr fails in line 202.
The text was updated successfully, but these errors were encountered: