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

VM deadlock during debugging (cache expansion/thread queue locks)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 1.1.5
    • Fix Version/s: 1.1.5
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      1.1.5
    • CPU:
      x86
    • OS:
      windows_95
    • Verification:
      Not verified

      Description



      Name: chT40241 Date: 10/22/97


      This problem can be observed debugging the Microsoft J++ sample applet under under HotJava. This situation can produce a number of different previously reported problems, so here is the description from one of them:

       >
       > D:\javabugs\sample>jdb "-Dhotjava.home=D:\Hotjava"
       > "-Dapplet.allow.namespace=true" sun.hotjava.Main
       > file:D:\javabugs\sample\sample.html
       > Initializing jdb...
       > 0xf73128:class(sun.hotjava.Main)
       > > stop in sample.init
       > Breakpoint set in sample.init
       > > run
       > run sun.hotjava.Main file:D:\javabugs\sample\sample.html
       > running ...
       > main[1] .Starting HotJava.
       > .Initializing globals.
       > .Creating frame.
       > .Loading: C:\\.hotjava\urlpool.
       > .Loaded DTD html32 in 687ms.
       >
       > Breakpoint hit: sample.init (sample:107)
       > thread applet-sample.class[1] list
       > 103 // CreateControls() method from within this method.
       > Remove the following
       > 104 // call to resize() before adding the call to
       > CreateControls();
       > 105 // CreateControls() does its own resizing.
       > 106
       > //----------------------------------------------------------------------
       > 107 => resize(320, 240);
       > 108
       > 109 // TODO: Place additional initialization code
       > here
       > 110 }
       > 111
       > thread applet-sample.class[1] next
       > thread applet-sample.class[1]
       
      The next command above never completes, because the StepHandler
      thread is in a deadly embrace with an AWT thread ("Image Animator").
      The ImageAnimator thread owns the cache expansion lock, and is waiting for the thread queue lock, while the StepHandler thread holds the queue lock and is waiting for the cache expansion lock.
       
      The problem was caused by a change to monitor_cache.c, which is
      described in the comments as a fix for green threads. The fix causes
      the thread queue lock to be obtained while holding the cache
      expansion lock. Unfortunately, the lock_for_debugger code in gc.c
      assumes that the relation between the two locks is in the other order,
      and locks the thread queue before taking the cache expansion lock.
      These two pieces of code need to take the locks in a consistent order.

      This problem seems to occur often when debugging this applet under HotJava; perhaps 20 % of the time.

      ======================================================================

        Attachments

          Activity

            People

            Assignee:
            never Tom Rodriguez
            Reporter:
            chickeysunw Chuck Hickey (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: