VisualVM
  1. VisualVM
  2. VISUALVM-129

Application node remains in Application window after kill -9 command on Linux and Solaris

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: dev
    • Component/s: code
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: All

    • Issuezilla Id:
      129

      Description

      After stop application by kill -9 command Application node remains in
      Application window. After that :

      • in Threads tab all threads a stopped
      • in Monitor tab all diagramms are still alive
      • in profiler tab after try to perform CPU or Memory profiling I've got
        empty Error message box.
        I've checked java processes using ps -ef |grep java - there are not anyone
        except for VisualVM.

        Activity

        Hide
        jsedlacek added a comment -

        This is reproducible always, at least on Linux. It looks like a bug in jvmstat
        and most likely won't be fixed in VisualVM.

        The workaround is to invoke 'jps' command after killing an application using
        'kill -9', this way jvmstat correctly determines finised applications.

        Show
        jsedlacek added a comment - This is reproducible always, at least on Linux. It looks like a bug in jvmstat and most likely won't be fixed in VisualVM. The workaround is to invoke 'jps' command after killing an application using 'kill -9', this way jvmstat correctly determines finised applications.
        Hide
        yardus added a comment -

        According to http://en.wikipedia.org/wiki/SIGKILL :
        "When sent to a program, SIGKILL causes it to terminate immediately. In contrast
        to SIGTERM and SIGINT, this signal cannot be caught or ignored, and the
        receiving process cannot perform any clean-up upon receiving this signal."
        The crucial part of the definition is that the receiving process *cannot perform
        any clean-up upon receiving this signal* - meaning there is no way of notifying
        jps system that the process has died. Thus jps will not notify about changes in
        the current process list till it is explicitly invoked.
        Performance-wise it's no good to call jps periodically only to detect the case
        when a process had been hard-killed - the only way would be to add a new action
        that would refresh all local applications.

        Show
        yardus added a comment - According to http://en.wikipedia.org/wiki/SIGKILL : "When sent to a program, SIGKILL causes it to terminate immediately. In contrast to SIGTERM and SIGINT, this signal cannot be caught or ignored, and the receiving process cannot perform any clean-up upon receiving this signal." The crucial part of the definition is that the receiving process *cannot perform any clean-up upon receiving this signal* - meaning there is no way of notifying jps system that the process has died. Thus jps will not notify about changes in the current process list till it is explicitly invoked. Performance-wise it's no good to call jps periodically only to detect the case when a process had been hard-killed - the only way would be to add a new action that would refresh all local applications.
        Hide
        thurka added a comment -

        I will try to work-around it somehow.

        Show
        thurka added a comment - I will try to work-around it somehow.

          People

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

            Dates

            • Created:
              Updated: