Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4469343

Heap snapshot causes signal 11

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      01
    • CPU:
      sparc
    • OS:
      generic
    • Verification:
      Verified

      Description

      Customer description of problem:

      With JDK 1.2.2
      ===============

      When we requested a heapdump through JVMPI it always appeared that a
      garbage
      collection was done before the heap dump was performed.

      With JDK 1.3.1 (released version)
      =================================

      When we request a heapdump it does not always seem to be the case that a
      Garbage collection is first performed. In some cases we have tracked the
      request being called of the JVM, but then the machine will not be
      responsive
      for up to 15 minutes and usually the JVM crashes.

      Even in cases where the heap dump succeeds, we see many objects in the
      dump without referrers or referees, which indicates that a gc has not taken
      place.
      One possibility which occurred to us is that this problem might be
      related to generational garbage collection, but we haven't been able to
      test this theory.

      However, if we request a Garbage collection manually through our
      app's interface first, we usually are able to take heap snapshots
      correctly. It also
      seems to be the case that if we add code to request a gc through JVMPI
      before requesting the heap dump, the heap dump operation completes as
      expected. We don't know why, but maybe through doing a garbage
      collection the heap information is better structured to allow for a
      heapdump (?).


      janet.koenig@Eng 2001-06-13


      karen.kinnear@East 2001-06-21

      Customer's small test case for duplicating:

      Attached to this bug report is examples.tar.gz. After gunzip
      and tar extracting it, run (UseBoundThreads they only use on Solaris)

      java -noclassgc -Xrunhprof:heap=dump -XX:+UseBoundThreads examples/profiler/applications/network/Network

      A small screen comes up - click the START button. Once the simulation
      has started, where you originally said java, now press CTRL \ which
      should give you a thread dump and a heap dump.

      See comments section for the 5 fixes for hprof to now work.

      To duplicate with JProbe:

      See Karen for a preliminary copy of JProbe 3.0 for Solaris.

      Install via java -Xmx100m -jar suite30_solaris.jar

      You also want the kknetwork.jpl file for initial settings. This is
      attached here.

      To run the profiler, execute "<JProbeDir>/profiler/jpprofiler -Dvmcheck=false

      After the "Welcome" dialog, click RUN which will bring you to
      the JProbe LaunchPad. Click "Load ..." and use the chooser to get
      the kknetwork.jpl file. Change the Workding Directory on the Program tab
      to be the JProbe install directory. On the VM tab change the VM path.
      You proably want to uncheck "close system console on exit". You
      can leave the existing VM arguments or add. Then just click
      Run and it will run the Network example (assumes that examples/...
      is in the JProbe30 directory - or a link is there).

      When you click RUN an xterm pops up with some JProbe debug and any
      VM debug info. On the "Runtime Heap Summary" there is a blue and pink
      memory use graph. On the toolbar, there is a group of buttons including
      a little yellow "mountain" and at the right end of that group a little
      camera whose tooltip says "Take Heap Snapshot". If you click that
      it should do a heap_dump.

      This JProbe version will print out debugging info like:

      jvmpi:RequestEvent(heap_dump, 0x...)
      jvmpi: 0x NotifyEvent(37:, requestedheap_dump) ...
      jvmpi::0x NotifyEvent() ok
      jvmpi: RequestEvent(): 0

      If you click on the camera a lot as the app is coming up and running it crashes
      trying to call RequestEvent (logging lines are flushed).

      (note: these instructions are from Sitraka and I ran them and it duplicated
      the problem - I did not try the manual instructions below)

      You can also run the viewer separately if you want to. From the LaunchPad, "Save As ..."
      your jpl file. From the the Program menu "Attach to remote session" and
      click ok. Then in a terminal window you can run
        "profiler/jprun -jp_input=/full/path/to/jpl"

      It should connect to the viewer and you can take heap snapshots again.
      You can skip jprun and go straight to java if you want, by adding
      the profiler directory to you PATH and LD_LIBRARY_PATH and setting
      the environment variable JPROBE_ARGS_0="-jp_input=/full/path/to/jpl",
      and running with "java -Xnoclassgc -Xbootclasspath/a:<JProbeDir>/profiler/jpagent.jar -Xrunjprobeagent etc."

      Note that the customer sees these problems on Win2000, Linux as well
      as Solaris.


        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mchung Mandy Chung
              Reporter:
              jkoenigsunw Janet Koenig (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: