Invalid PID retrieved for SOLARIS SPARC Environment #4872
Comments
|
Yeah I would guess in this environment it's not using our native process logic, which would mean that the pid is hidden inside a JDK-provided class. Are you able to assist us investigating this? I do not have access to a sparcv9 system. |
|
Hi Headius, sorry for the late reply. I do have access to some sparc systems, so in a way I can play remote-hands for you to debug this issue. But coming from the different JRuby versions, I would guess a change happened between both, i.e. between 2017-05-11 and 2017-09-06 which led to this error. So, any commands or scripts I can run for you, to shed more light into this ? Best wishes, |
|
@Tribbles01 Sorry for silence over the holiday season! Since you have a date range, perhaps you could bisect and find out which commit introduced it? There's instructions on building a local JRuby in BUILDING.md. |
|
Hi Headius, it took me a bit of time to prepare the build environment, as I barely know about maven and the likes. After the build, I did this little check routine: bash-4.4$ for i in There you can see that the last 1.7 Release works as supposed, returning a correct PID Number. I tried to build the 9.0.1.0 Version, but this build fails like this: [ SNIP ] I think this is as far as I can go, hope this may set you right on track. Best wishes, |
|
One more note, perhaps the system architecture was not recognized correctly. See [SunOS-sparcv9] vs. [solaris-sparcv9] in the --version info above ... Best wishes, |
|
Hi Headius, I made some more inspections and now I am quite sure, that the CPU ARchitecture detection does not work for SPARC systems. jruby-9.1.13.0/lib/ruby/stdlib/ffi/platform/x86_64-solaris/fcntl.rb Now, comparing the Makefiles you have a difference in the setup. The relevant part of the 1.7 Makefile: ifeq ($(OS), solaris) In comparison to the 9.X spec/ffi/fixtures/GNUmakefile: Also note, that the CC Path does not need to be correct for sparc environments ... only if the SunFreeware (as in sfw) gcc package has been installed ... This is as far as I can get, I am not sure on how to update the necessary build files to correctly determine the OS and CPU .. BUT from what I can see in the Makefiles, this may help: bash-4.4$ uname -m Best wishes, |
|
Ok, thank you for the additional investigation. There is indeed no reference to "sun4v" in any of our platform detection, so that's likely causing the issues. @Tribbles01 Can you show me what |
|
I'm downloading an x86 solaris vbox image, but I'm not sure I'll be able to reproduce the same issues there. The pid capture/detection logic happens in one of two ways:
I would hope the former is working, but for whatever reason native process logic may not be loading on sparc. If we are falling back on the latter, I would have expected existing logic for digging the pid out of a unix-style JVM Process to work just the same on solaris/sparc, but that may not be the case. |
|
Hi Headius, I fear this will not help you mcuh further, if you check the output : xy@123:~/jruby-1.7.27$ ./bin/jruby -e 'p ENV_JAVA["os.name"]' xy@123:~/jruby-9.1.15.0$ ./bin/jruby -e 'p ENV_JAVA["os.name"]' But digging furhther unto ENV_JAVA, perhaps this may be something to look at: xy@123:~/jruby-9.1.15.0$ ./bin/jruby -e 'p ENV_JAVA["os.arch"]' xy@123:~/jruby-1.7.27$ ./bin/jruby -e 'p ENV_JAVA["os.arch"]' Thanks for your help, |
|
Ok thank you! The OS appears to be detecting properly, since we recognize |
|
Hi Headius, thanks for commenting. If there's anything left I can do to support, please let me know. Thorsten |
|
Any news on this issue ? Thorsten |
|
Sorry for delays here...I have not found any likely cause for this issue yet. Perhaps you could gist the output of Also provide the output of running with |
|
Hi Headius, I did both commands on the 1.7 and 9.1 version so these can be checked against. for Version 1.7: bash-4.4$ ./jruby-1.7.27/bin/jruby -Xnative.enabled=false -Xnative.verbose=true -Xnative.net.protocol=true -e 'pipe=IO.popen("sleep 3"); puts pipe.pid; puts File.blockdev?("/")' For Version 9.1: bash-4.4$ ./jruby-9.1.15.0/bin/jruby -J-verbose:jni -e 1 bash-4.4$ ./jruby-9.1.15.0/bin/jruby -Xnative.enabled=false -Xnative.verbose=true -Xnative.net.protocol=true -e 'pipe=IO.popen("sleep 3"); puts pipe.pid; puts File.blockdev?("/")' Hope this helps out, |
|
Any updates on this? |
|
As this issue is lingering for about a year now ... anything new in it ? And just as a note, it still seems to not be able to run in a Solaris SPARC environment, as I did some tests with this version: $ ./jruby --version following up to your question above, what may be interesting is this: $ ./jruby -J-verbose:jni -e 1 ------------------ BUT ---------------------- require at org/jruby/RubyKernel.java:955 at uri:classloader:/jruby/kernel/file.rb:1 load at org/jruby/RubyKernel.java:973 at uri:classloader:/jruby/kernel/file.rb:191 [Dynamic-linking native method java.lang.Shutdown.halt0 ... JNI] And just as a little note, if this issue won't get fixed at all, I will have a production breaking issue which means to re-write that whole application in another language ......... Tribbles |
First of all, this is my very first post / Bug Report, so I try to be as complete as possible...
I did some testing with JRuby in my Solaris Sparc environment and had to find that some very basic functionality does not work anymore, in contrast to JRuby V1.9
Environment
Provide at least:
jruby -v) and command line (flags, JRUBY_OPTS, etc)$ ./bin/jruby --version
jruby 9.1.13.0 (2.3.3) 2017-09-06 8e1c115 Java HotSpot(TM) 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [solaris-sparcv9]
uname -a)$ uname -a
SunOS 5.11 11.3 sun4v sparc sun4v
Other relevant info you may wish to add:
No additional installation has happened, just used the lastest stable JRuby binary
Expected Behavior
Expected behaviour would be like this, as per outlined command call:
$ ./bin/jruby --version
jruby 1.7.27 (1.9.3p551) 2017-05-11 8cdb01a on Java HotSpot(TM) 64-Bit Server VM 1.8.0_144-b01 +jit [SunOS-sparcv9]
$ LD_LIBRARY_PATH="/lib/64" ./bin/jruby -Xnative.verbose=true -Xnative.net.protocol=true -e 'pipe=IO.popen("sleep 3"); puts pipe.pid; puts File.blockdev?("/")'
Successfully loaded native POSIX impl.
10486
false
Actual Behavior
$ ./bin/jruby --version
jruby 9.1.13.0 (2.3.3) 2017-09-06 8e1c115 Java HotSpot(TM) 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [solaris-sparcv9]
$ LD_LIBRARY_PATH="/lib/64" ./bin/jruby -Xnative.verbose=true -Xnative.net.protocol=true -e 'pipe=IO.popen("sleep 3"); puts pipe.pid; puts File.blockdev?("/")'
Successfully loaded native POSIX impl.
51582567331272
false
As you can see, the returned PID as far out of bounds, so any subsequent call like waitfor on this pid, do fail....
Best wishes,
Thorsten
The text was updated successfully, but these errors were encountered: