Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bad value for $$ #3380

Closed
donv opened this issue Oct 9, 2015 · 14 comments
Closed

Bad value for $$ #3380

donv opened this issue Oct 9, 2015 · 14 comments
Assignees
@mkristian
Labels
JRuby 9000
Milestone
JRuby 9.0.2.0

Comments

@donv
Copy link
Member

donv commented Oct 9, 2015

Hi!

On one production machine we are getting a strange value for $$:

# jruby -e 'puts $$'
1252169911

This is the same value as the hash of the runtime mentioned in #2452:

# jruby -e "p java.lang.System.identity_hash_code(JRuby.runtime)"
1252169911

We have not been able to reproduce this on any other physical or virtual machine, and we have no idea where to start. Any help is greatly appreciated.

The machine is a newly installed Ubuntu 14.04 trusty 64-bit server. We are running with JRuby 9.0.1.0 on Oracle Java 1.8.0_60:

# jruby -v
jruby 9.0.1.0 (2.2.2) 2015-09-02 583f336 Java HotSpot(TM) 64-Bit Server VM 25.60-b23 on 1.8.0_60-b27 +jit [linux-amd64]
@donv donv added the JRuby 9000 label Oct 9, 2015
@donv donv added this to the JRuby 9.0.2.0 milestone Oct 9, 2015
@donv
Copy link
Member Author

donv commented Oct 9, 2015

One other symptom (may be unrelated), is that RAILS_ENV was not propagated to a daemonized puma instance. Running puma without -d (not daemonized) works as expected. I suspect both daemonization and fetching process id are both posix functions, which is why I think they might be related. Just a hunch.

@donv
Copy link
Member Author

donv commented Oct 9, 2015

Process.pid gives the same value:

# jruby -e 'puts Process.pid'
1252169911

@headius
Copy link
Member

headius commented Oct 12, 2015

This should only happen when native support can't be loaded, since in that case there's no portable way to get the current process's pid. That might also explain env values not propagating correctly, since it would fall back on older, crufty process logic. Can you check output of -Xnative.verbose=true?

@donv
Copy link
Member Author

donv commented Oct 14, 2015

I have not verified yet (need access to the production server again), but I think issue #3285 may be the cause here. Can that be?

I'll try to verify with -Xnative.verbose=true as soon as I can. cc: @larsin

@donv
Copy link
Member Author

donv commented Oct 14, 2015

We have verified that the error goes away by installing libc6-dev on the server. Woohoo!

Will installing libc6-dev still be necessary with JRuby 9.0.2.10?

@enebo
Copy link
Member

enebo commented Oct 14, 2015

@donv I just updated jnr-posix which should be a newer ffi but I see you still needed to include this. Was @mkristian fix in #3285 dependent on still needing this libc6-dev?

@donv
Copy link
Member Author

donv commented Oct 14, 2015

@enebo @headius @mkristian It is unclear to me if libc6-dev is still needed after the #3285 fix. It would be good if you could clarify.

@enebo
Copy link
Member

enebo commented Oct 15, 2015

@donv by you ewe meant @mkristian ... :)

@mkristian
Copy link
Member

@donv not sure why it did not pick the x86_64 library

 $ bin/jruby -Xnative.enabled=true -Xnative.verbose=true -e "p File::Stat.new('/').blockdev?"
Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows.
java.lang.UnsatisfiedLinkError: /lib/i386-linux-gnu/libcrypt.so.1: wrong ELF class: ELFCLASS32
    at jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:87)
    at jnr.ffi.provider.jffi.NativeLibrary.getNativeLibraries(NativeLibrary.java:70)
    at jnr.ffi.provider.jffi.NativeLibrary.getSymbolAddress(NativeLibrary.java:49)
    at jnr.ffi.provider.jffi.NativeLibrary.findSymbolAddress(NativeLibrary.java:59)
    at jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:117)
    at jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:59)
    at jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:43)
    at jnr.ffi.LibraryLoader.load(LibraryLoader.java:290)
    at jnr.ffi.Library.loadLibrary(Library.java:127)
    at jnr.posix.POSIXFactory$DefaultLibCProvider$SingletonHolder.<clinit>(POSIXFactory.java:279)
    at jnr.posix.POSIXFactory$DefaultLibCProvider.getLibC(POSIXFactory.java:283)
    at jnr.posix.BaseNativePOSIX.<init>(BaseNativePOSIX.java:36)
    at jnr.posix.LinuxPOSIX.<init>(LinuxPOSIX.java:18)
    at jnr.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:143)
    at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:121)
    at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:90)
    at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:36)
    at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:32)
    at jnr.posix.LazyPOSIX.isNative(LazyPOSIX.java:370)
    at org.jruby.RubyGlobal.prepareStdioChannel(RubyGlobal.java:279)
    at org.jruby.RubyGlobal.createGlobals(RubyGlobal.java:194)
    at org.jruby.Ruby.init(Ruby.java:1238)
    at org.jruby.Ruby.newInstance(Ruby.java:330)
    at org.jruby.Main.internalRun(Main.java:272)
    at org.jruby.Main.run(Main.java:233)
    at org.jruby.Main.main(Main.java:200)
NotImplementedError: block device detection unsupported or native support failed to load
  blockdev? at org/jruby/RubyFileStat.java:172
      <top> at -e:1

@mkristian
Copy link
Member

@headius reading this I wondered whether these two lines of mine do miss something (possible SecurityException or very expensive to use JMX here, or ...)
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/util/JRubyClassLoader.java#L74
?

@mkristian
Copy link
Member

regarding my stacktrace, I do have multiarch support installed

@donv
Copy link
Member Author

donv commented Oct 20, 2015

@enebo @headius @mkristian Sorry for needing it fed with a tea spoon: Will we need to install the libc6-dev package for JRuby 9.0.2.0 ?

@mkristian
Copy link
Member

it depends. if you have a multiarch setup then there is a new problem with new jffi jar. so not sure if we should go back and first fix the mutliarch problem. but that is probably a new issue.

if you have a clean x86_64 linux you do not need to install libc6-dev or build-essentials, etc

@donv
Copy link
Member Author

donv commented Oct 21, 2015

@mkristian Thanks!

@donv donv closed this as completed Oct 21, 2015
@mkristian mkristian mentioned this issue Oct 22, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mkristian mkristian

Labels
JRuby 9000
Projects
None yet
Milestone
JRuby 9.0.2.0
Development

No branches or pull requests
4 participants
@headius @enebo @mkristian @donv