Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.7.0
    • Fix Version/s: JRuby 1.7.3
    • Component/s: Launcher, Windows
    • Labels:
      None
    • Environment:
      jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_09-b05 [Windows Vista-x86]
    • Number of attachments :
      0

      Description

      JRuby cannot find Java through JAVA_HOME when option -w is used and JAVA_HOME points to a JRE.

      If JAVA_HOME points to a JDK the problems disappears.

      The following example shows how JAVA_HOME first pointing to the JDK, then to the JRE:

      D:\>set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_09
      
      D:\>jruby -v
      jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_0
      9-b05 [Windows Vista-x86]
      
      D:\>jruby -e "puts 'a'"
      a
      
      D:\>jruby -w -e "puts 'a'"
      a
      
      D:\>set JAVA_HOME=C:\Program Files\Java\jre7
      
      D:\>jruby -v
      jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_0
      9-b05 [Windows Vista-x86]
      
      D:\>jruby -e "puts 'a'"
      a
      
      D:\>jruby -w -e "puts 'a'"
      Cannot locate Java installation, specified by JAVA_HOME:
      

        Activity

        Hide
        Claus Folke Brobak added a comment -

        I just tried the same thing on a Windows XP computer and cannot reproduce the error, so it might be specific to Windows Vista.

        D:\> set JAVA_HOME
        JAVA_HOME=C:\Program Files\Java\jre7
        
        D:\> jruby -v
        jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_0
        9-b05 [Windows XP-x86]
        
        D:\> jruby -e "puts 'a'"
        a
        
        D:\> jruby -w -e "puts 'a'"
        a
        
        
        Show
        Claus Folke Brobak added a comment - I just tried the same thing on a Windows XP computer and cannot reproduce the error, so it might be specific to Windows Vista. D:\> set JAVA_HOME JAVA_HOME=C:\Program Files\Java\jre7 D:\> jruby -v jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_0 9-b05 [Windows XP-x86] D:\> jruby -e "puts 'a'" a D:\> jruby -w -e "puts 'a'" a
        Hide
        Claus Folke Brobak added a comment - - edited

        The problem still exists with JRuby 1.7.1. However, further testing revealed that the order of options is important:

        C:\>set JAVA_HOME
        JAVA_HOME=C:\Program Files\Java\jre7
        
        C:\>jruby -e "puts 'a'"
        a
        
        C:\>jruby -w -e "puts 'a'"
        Cannot locate Java installation, specified by JAVA_HOME:
        
        
        C:\>jruby -e "puts 'a'" -w
        a
        
        C:\>
        

        I also noticed that the problem is the same if option "-v" is used.

        Show
        Claus Folke Brobak added a comment - - edited The problem still exists with JRuby 1.7.1. However, further testing revealed that the order of options is important: C:\>set JAVA_HOME JAVA_HOME=C:\Program Files\Java\jre7 C:\>jruby -e "puts 'a'" a C:\>jruby -w -e "puts 'a'" Cannot locate Java installation, specified by JAVA_HOME: C:\>jruby -e "puts 'a'" -w a C:\> I also noticed that the problem is the same if option "-v" is used.
        Hide
        Thomas E Enebo added a comment -

        Confirmed on my machine...this is pretty weird

        Show
        Thomas E Enebo added a comment - Confirmed on my machine...this is pretty weird
        Hide
        Thomas E Enebo added a comment -

        Claus, master of jruby has updated windows binaries with a fix. There is something really strange in C++ where I think a std::string was taking ownership of the char * we used as a base for searching for JVM homes. A particular method would erase some strings and since the pointers ownership changed it was also erasing the our base search string.

        tbh, I am unclear why this solves the problem as described other than noticing it was making a string "" which shouldn't be. Once I fixed this all seemed to be well though. Could you please confirm your problem has been resolved?

        To answer another nagging question: This was a regression. I updated to a new g++ and that required some code changes to even compile. The outcome was something else involving perhaps? std::string overload for '=' involving a const char *? I would have only claimed to know C++ with any reasonable knowledge about 20 years ago, so the more complicated stdlib gets the most lost I get now.

        Show
        Thomas E Enebo added a comment - Claus, master of jruby has updated windows binaries with a fix. There is something really strange in C++ where I think a std::string was taking ownership of the char * we used as a base for searching for JVM homes. A particular method would erase some strings and since the pointers ownership changed it was also erasing the our base search string. tbh, I am unclear why this solves the problem as described other than noticing it was making a string "" which shouldn't be. Once I fixed this all seemed to be well though. Could you please confirm your problem has been resolved? To answer another nagging question: This was a regression. I updated to a new g++ and that required some code changes to even compile. The outcome was something else involving perhaps? std::string overload for '=' involving a const char *? I would have only claimed to know C++ with any reasonable knowledge about 20 years ago, so the more complicated stdlib gets the most lost I get now.
        Hide
        Claus Folke Brobak added a comment -

        Thomas, looking here http://ci.jruby.org/snapshots/master/ the newest binary is from 19-Feb-2013. Am I looking in the wrong place?

        Show
        Claus Folke Brobak added a comment - Thomas, looking here http://ci.jruby.org/snapshots/master/ the newest binary is from 19-Feb-2013. Am I looking in the wrong place?
        Hide
        Thomas E Enebo added a comment -

        If you have a clone from our git repository: https://github.com/jruby/jruby you can get them without building. I am not sure why latest nightly has not produced them. You can also grab them from githib.com if you just want to get the binaries are try them in an existing installation:

        https://github.com/jruby/jruby/blob/master/bin/jruby.exe
        https://github.com/jruby/jruby/blob/master/bin/jrubyw.exe
        https://github.com/jruby/jruby/blob/master/bin/jruby.dll

        and install these into an existing JRuby installation.

        Show
        Thomas E Enebo added a comment - If you have a clone from our git repository: https://github.com/jruby/jruby you can get them without building. I am not sure why latest nightly has not produced them. You can also grab them from githib.com if you just want to get the binaries are try them in an existing installation: https://github.com/jruby/jruby/blob/master/bin/jruby.exe https://github.com/jruby/jruby/blob/master/bin/jrubyw.exe https://github.com/jruby/jruby/blob/master/bin/jruby.dll and install these into an existing JRuby installation.
        Hide
        Claus Folke Brobak added a comment -

        I have now tested the new version of the launcher on two computers running Windows Vista and Windows 7. The problem was present before installing the new launcher and gone after installing it.

        Show
        Claus Folke Brobak added a comment - I have now tested the new version of the launcher on two computers running Windows Vista and Windows 7. The problem was present before installing the new launcher and gone after installing it.
        Hide
        Thomas E Enebo added a comment -

        Great based on that I am resolving this one. Thanks for testing and I just released JRuby 1.7.3 so the new launcher is in there and ready to go.

        Show
        Thomas E Enebo added a comment - Great based on that I am resolving this one. Thanks for testing and I just released JRuby 1.7.3 so the new launcher is in there and ready to go.
        Hide
        Tim Hayman added a comment -

        I think this fix is working around the problem described in JRUBY-7096 – the stack is being corrupted in PlatformLauncher::checkJDKHome. The corrupt stack causes the random behaviour noted in this bug.

        By introducing a new stack variable in this fix, I believe the corruption has shifted around and it's not producing the same problem but the underlying corruption is still there.

        Show
        Tim Hayman added a comment - I think this fix is working around the problem described in JRUBY-7096 – the stack is being corrupted in PlatformLauncher::checkJDKHome. The corrupt stack causes the random behaviour noted in this bug. By introducing a new stack variable in this fix, I believe the corruption has shifted around and it's not producing the same problem but the underlying corruption is still there.

          People

          • Assignee:
            Thomas E Enebo
            Reporter:
            Claus Folke Brobak
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: