JRuby

random seed for srand is not initialized properly

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.6.6
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    1.6 series (1.7.0.dev is safe)
  • Number of attachments :
    0

Description

This happens after updating rspec from 2.7.0 to 2.8.0, rspec-rails to 2.8.1.

See: https://gist.github.com/1573648

Additionally updated gems compared to the working version are:

  • rack 1.3.5 ==> 1.3.6
  • rdoc 3.11 ==> 3.12

There must be something in there.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dmytrii Nagirniak added a comment -

Forgot to mention the json has also changed.

Show
Dmytrii Nagirniak added a comment - Forgot to mention the json has also changed.
Hide
Permalink
Charles Oliver Nutter added a comment -

Minimal reproduction:

system ~/projects/jruby2 $ bin/jruby --1.9 -e "srand % 0xFFFF"
CachingCallSite.java:418:in `pollAndGetClass': java.lang.NullPointerException
	from CachingCallSite.java:164:in `call'
	from -e:1:in `__file__'
	from -e:-1:in `load'
	from Ruby.java:695:in `runScript'
	from Ruby.java:688:in `runScript'
	from Ruby.java:595:in `runNormally'
	from Ruby.java:444:in `runFromMain'
	from Main.java:329:in `doRunFromMain'
	from Main.java:241:in `internalRun'
	from Main.java:207:in `run'
	from Main.java:191:in `run'
	from Main.java:171:in `main'

The problem here is that the 1.9-mode srand returns the old seed, but the seed is not initialized to anything at boot. As a result, the old seed for the first call is null, which propagates into the system and eventually causes a call site to blow up.

This only occurs on the 1.6 line, but is obviously present up through 1.6.5.1. A fix will be in 1.6.6...I have a patch in progress.

A workaround is to make a call to srand earlier and never use the result. This causes the global seed to have a value for future calls.

Show
Charles Oliver Nutter added a comment - Minimal reproduction: system ~/projects/jruby2 $ bin/jruby --1.9 -e "srand % 0xFFFF" CachingCallSite.java:418:in `pollAndGetClass': java.lang.NullPointerException from CachingCallSite.java:164:in `call' from -e:1:in `__file__' from -e:-1:in `load' from Ruby.java:695:in `runScript' from Ruby.java:688:in `runScript' from Ruby.java:595:in `runNormally' from Ruby.java:444:in `runFromMain' from Main.java:329:in `doRunFromMain' from Main.java:241:in `internalRun' from Main.java:207:in `run' from Main.java:191:in `run' from Main.java:171:in `main' The problem here is that the 1.9-mode srand returns the old seed, but the seed is not initialized to anything at boot. As a result, the old seed for the first call is null, which propagates into the system and eventually causes a call site to blow up. This only occurs on the 1.6 line, but is obviously present up through 1.6.5.1. A fix will be in 1.6.6...I have a patch in progress. A workaround is to make a call to srand earlier and never use the result. This causes the global seed to have a value for future calls.
Hide
Permalink
Charles Oliver Nutter added a comment -

commit 0bd3bd0c1f9a1a1470c68426d6f48ded66e1e611
Author: Charles Oliver Nutter <headius@headius.com>
Date: Sat Jan 7 01:19:21 2012 -0600

Fix JRUBY-6324: `pollAndGetClass': java.lang.NullPointerException

The problem here was that srand's global seed was not initialized
at boot, resulting in the first call returning null. That null
propagated into Ruby execution, eventually blowing up in a call
site.

My fix is to make an initial call to the srand logic, creating a
first seed.

Show
Charles Oliver Nutter added a comment - commit 0bd3bd0c1f9a1a1470c68426d6f48ded66e1e611 Author: Charles Oliver Nutter <headius@headius.com> Date: Sat Jan 7 01:19:21 2012 -0600 Fix JRUBY-6324 : `pollAndGetClass': java.lang.NullPointerException The problem here was that srand's global seed was not initialized at boot, resulting in the first call returning null. That null propagated into Ruby execution, eventually blowing up in a call site. My fix is to make an initial call to the srand logic, creating a first seed.
Hide
Permalink
Hiroshi Nakamura added a comment -

Initial seed value for the runtime-local PRNG is not initialized properly. It is 0 for 1.8 and null for 1.9.

% jruby165 -e 'p srand'
0
% jruby165 --1.9 -e 'srand.fire'
CachingCallSite.java:418:in `pollAndGetClass': java.lang.NullPointerException
	from CachingCallSite.java:130:in `call'
	from -e:1:in `__file__'
	from -e:-1:in `load'
	from Ruby.java:693:in `runScript'
	from Ruby.java:686:in `runScript'
	from Ruby.java:593:in `runNormally'
	from Ruby.java:442:in `runFromMain'
	from Main.java:321:in `doRunFromMain'
	from Main.java:241:in `internalRun'
	from Main.java:207:in `run'
	from Main.java:191:in `run'
	from Main.java:171:in `main'
zsh: exit 1     /home/nahi/java/jruby-1.6.5/bin/jruby --1.9 -e 'srand.fire'

And newly generated seeds are similar, though it's not clear this similarity causes a problem or not.

% jruby165 -e 'p [srand, srand]'
[0, 1325940420306]
% jruby165 -e 'p [srand, srand]'
[0, 1326059397765]

(13259404020306 =~ 1326059397765)

It's jruby <= 1.6 specific problem. Master branch does not have both issues since we already replaced Random implementations with Mersenne Twister.

Show
Hiroshi Nakamura added a comment - Initial seed value for the runtime-local PRNG is not initialized properly. It is 0 for 1.8 and null for 1.9. % jruby165 -e 'p srand' 0 % jruby165 --1.9 -e 'srand.fire' CachingCallSite.java:418:in `pollAndGetClass': java.lang.NullPointerException from CachingCallSite.java:130:in `call' from -e:1:in `__file__' from -e:-1:in `load' from Ruby.java:693:in `runScript' from Ruby.java:686:in `runScript' from Ruby.java:593:in `runNormally' from Ruby.java:442:in `runFromMain' from Main.java:321:in `doRunFromMain' from Main.java:241:in `internalRun' from Main.java:207:in `run' from Main.java:191:in `run' from Main.java:171:in `main' zsh: exit 1 /home/nahi/java/jruby-1.6.5/bin/jruby --1.9 -e 'srand.fire' And newly generated seeds are similar, though it's not clear this similarity causes a problem or not. % jruby165 -e 'p [srand, srand]' [0, 1325940420306] % jruby165 -e 'p [srand, srand]' [0, 1326059397765] (13259404020306 =~ 1326059397765) It's jruby <= 1.6 specific problem. Master branch does not have both issues since we already replaced Random implementations with Mersenne Twister.
Hide
Permalink
Hiroshi Nakamura added a comment -

Here's additional fix for jruby-1_6.

commit f7041c2636f46e398e3994fba2045e14a890fc14
Author: Hiroshi Nakamura <nahi@ruby-lang.org>
Date:   Tue Jan 10 23:54:48 2012 +0900

    JRUBY-6324: random seed for srand is not initialized properly
    
    jruby -e 'p srand' returns previous (initial) srand seed.  In 1.8 mode,
    it always returns 0 but it's not correct.  In 1.9 mode, it crashes with
    NullPointerException because it returns null as RubyObject.  Anyway,
    initial seed value is not initialized properly.
    
    This commit includes several fixes for Random.
    
    * Initialize the runtime-local PRNG and seed at Ruby#initCore().
    
    * Keep seed for PRNG as not long but RubyInteger.
      % jruby165 -e 'n = 2**128; srand(n); p [n.object_id, srand.object_id]'
      [2000, 1] => should be the same object
    
    * Introduced Ruby#randomSeedRandom as the runtime-local PRNG for
      generating seed by srand.  Do not use System.currentTimeMillis which
      is not suited for PRNG seed.
    
    * Removed globalRandom in RubyRandom class which is used only in 1.9
      mode.  Use Ruby#getRandom() for global srand as same as 1.8 mode.

It passes ant test and ant spec.

Show
Hiroshi Nakamura added a comment - Here's additional fix for jruby-1_6. commit f7041c2636f46e398e3994fba2045e14a890fc14 Author: Hiroshi Nakamura <nahi@ruby-lang.org> Date: Tue Jan 10 23:54:48 2012 +0900 JRUBY-6324: random seed for srand is not initialized properly jruby -e 'p srand' returns previous (initial) srand seed. In 1.8 mode, it always returns 0 but it's not correct. In 1.9 mode, it crashes with NullPointerException because it returns null as RubyObject. Anyway, initial seed value is not initialized properly. This commit includes several fixes for Random. * Initialize the runtime-local PRNG and seed at Ruby#initCore(). * Keep seed for PRNG as not long but RubyInteger. % jruby165 -e 'n = 2**128; srand(n); p [n.object_id, srand.object_id]' [2000, 1] => should be the same object * Introduced Ruby#randomSeedRandom as the runtime-local PRNG for generating seed by srand. Do not use System.currentTimeMillis which is not suited for PRNG seed. * Removed globalRandom in RubyRandom class which is used only in 1.9 mode. Use Ruby#getRandom() for global srand as same as 1.8 mode. It passes ant test and ant spec.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Dmytrii Nagirniak
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: