Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.5
    • Fix Version/s: 1.3.5
    • Component/s: None
    • Labels:
      None
    • Environment:

      Windows 7 Pro
      Java 1.7.0_5 or _9, 64-bit
      Eclipse Juno (4.2)

      Description

      Selected version 1.3.4 in the Affects Version/s list, because 1.3.5 isn't listed yet...

      When I run VisualVM 1.3.5 (standalone) on Windows 7 Pro, Eclipse Juno (4.2, 64bit, run with Java 1.7.0_5 or _9) becomes frozen: I cannot bring it to front from the task bar, although I can see it in the small preview. I can iconify windows to see the window, but it doesn't react to clicks, etc. As if a glass pane was in front of it. Windows doesn't report it as non responsive. A simple close window command from the task bar is ineffective, I have to kill the process from the task manager.

      Closing VisualVM doesn't solve the issue...

      If I start VisualVM first, Eclipse remains stuck on the splash screen.

        Activity

        Hide
        philho added a comment -

        Same problem with Eclipse Indigo (3.7) on similar environment.
        Eclipse is seen as "Local application", with a generic icon.
        If I run the JVisualVM of Java 1.7.0_09, it shows Eclipse by its name, with its icon, and the problem doesn't happen.

        Show
        philho added a comment - Same problem with Eclipse Indigo (3.7) on similar environment. Eclipse is seen as "Local application", with a generic icon. If I run the JVisualVM of Java 1.7.0_09, it shows Eclipse by its name, with its icon, and the problem doesn't happen.
        Hide
        thurka added a comment -

        Can you please tell me on which JDK (32bit or 64bit) do you run VisualVM 1.3.5 ? It looks like JVisualVM is running 64bit JDK, while VisualVM 1.3.5 is running 32bit JDK.

        Show
        thurka added a comment - Can you please tell me on which JDK (32bit or 64bit) do you run VisualVM 1.3.5 ? It looks like JVisualVM is running 64bit JDK, while VisualVM 1.3.5 is running 32bit JDK.
        Hide
        thurka added a comment -

        We can confirm that this is happening when you run VisualVM on different architecture (32bit versus 64bit) than monitored application. This is WIndows only issue.

        Show
        thurka added a comment - We can confirm that this is happening when you run VisualVM on different architecture (32bit versus 64bit) than monitored application. This is WIndows only issue.
        Hide
        philho added a comment -

        Ah, since the binary is a simple exe, I had no second thoughts about this...
        I am not in front of the computer where I reported this, but I know that the installed JRE (in the system) is Java 7, 32bit edition, because we have to run our software with this version from Java Web start.
        JAVA_HOME might point somewhere else (a JDK), but I don't know if you use this environment variable.

        As reported, Eclipse does run on a 64bit JVM.

        Show
        philho added a comment - Ah, since the binary is a simple exe, I had no second thoughts about this... I am not in front of the computer where I reported this, but I know that the installed JRE (in the system) is Java 7, 32bit edition, because we have to run our software with this version from Java Web start. JAVA_HOME might point somewhere else (a JDK), but I don't know if you use this environment variable. As reported, Eclipse does run on a 64bit JVM.
        Hide
        thurka added a comment -

        Fixed in revision 3176.

        bugfix #533, on Windows, try to attach only to process with he the same architecture (32bit/64bit)

        Show
        thurka added a comment - Fixed in revision 3176. bugfix #533, on Windows, try to attach only to process with he the same architecture (32bit/64bit)
        Hide
        philho added a comment -

        You mean VisualVM attaches itself to all Java processes it finds as soon as it starts?
        Because the freezing happens when I run it, without even taking an action in it.

        It is great if you found a fix.

        How do we choose on which VM VisualVM will run? On Windows, it is a simple .exe file, I see no .ini file like Eclipse has (allowing to specify the Java to use). I don't know if it uses the default Java runtime put at C:\Windows\system32\java.exe by the last Java installer, or the one specified by JAVA_HOME (not really, actually, according to my test) or something else.

        I mean, I might want to examine 32- or 64-bit Java programs, so I need to run VisualVM with the same VM than the one they use (I always have several JDK on my system...), so I need a mean (command line option?) to specify it.

        Show
        philho added a comment - You mean VisualVM attaches itself to all Java processes it finds as soon as it starts? Because the freezing happens when I run it, without even taking an action in it. It is great if you found a fix. How do we choose on which VM VisualVM will run? On Windows, it is a simple .exe file, I see no .ini file like Eclipse has (allowing to specify the Java to use). I don't know if it uses the default Java runtime put at C:\Windows\system32\java.exe by the last Java installer, or the one specified by JAVA_HOME (not really, actually, according to my test) or something else. I mean, I might want to examine 32- or 64-bit Java programs, so I need to run VisualVM with the same VM than the one they use (I always have several JDK on my system...), so I need a mean (command line option?) to specify it.
        Hide
        thurka added a comment -

        Try to run
        visualvm.exe --help
        from commandline to get list of commandline options.

        Show
        thurka added a comment - Try to run visualvm.exe --help from commandline to get list of commandline options.
        Hide
        thurka added a comment -

        The fix is also available on 1.3.5 plugin center.

        Show
        thurka added a comment - The fix is also available on 1.3.5 plugin center.

          People

          • Assignee:
            thurka
            Reporter:
            philho
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: