JDK-4367942 : Stopping a HotSpot debug session leaves behind a javaw.exe.
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2000-09-01
  • Updated: 2002-01-10
  • Resolved: 2001-04-30
Related Reports
Duplicate :  
JDK-4420844 - JPDA: Debugger operations after VM death cause errors
Relates :  
JDK-4368399 - JDI: -verbose option passed to debugger launcher fails and hangs vm
Description

Name: dc32491			Date: 09/01/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

Debug any program using HotSpot.  Stop the debug session.  Notice javaw.exe
remains in system process list.  Below is a test program.

------------
public class Untitled1 {
  public Untitled1() {
  }

  public static void main(String[] args) {
    Untitled1 untitled1 = new Untitled1();
  }
}
(Review ID: 109210) 
======================================================================
Comments
SUGGESTED FIX This fix can ameliorate this problem, but some more general fix is needed too. In 1.3.1, file ./share/transport/socket/socketTransport.c contains this func: recv_fully(int f, char *buf, int len) { int nbytes = 0; while (nbytes < len) { int res = dbgsysRecv(f, buf + nbytes, len - nbytes, 0); if (res < 0) { return res; } nbytes += res; } return nbytes; } At least on solaris-sparc, if the FE goes away during this loop, the dbgSysRecv call returns 0 resulting in an inf. loop. Thus, not only does the debuggee become an orphan, it becomes a a really bad orphan consuming lots of CPU cycles. This has been fixed in 1.4 by : static jint recv_fully(int f, char *buf, int len) { int nbytes = 0; while (nbytes < len) { int res = dbgsysRecv(f, buf + nbytes, len - nbytes, 0); if (res < 0) { return res; } else if (res == 0) { break; /* eof, return nbytes which is less than len */ } nbytes += res; } return nbytes; } With this fix in place, orphans still appear on solaris when the program being debugged exits. However, when the debugger itself, eg, Forte, exits, the orphans all disappear. So, this fix doesn't help the problem on NT when the shmem transport is used. And, it doesn't completely cure the problem on solaris. I don't know just what it is that causes the 0 len to be returned in the above func - maybe when the socket is actually closed or released, and maybe the FE or the debugger is accidently hanging onto these sockets until it exits.
11-06-2004
EVALUATION VMDeath is a SUSPEND_ALL event. If the debugger that catches this doesn't do a resume, or a vm.exit() or a vm.dispose(), then it seems likely that this will occur. So, we might end up saying this is a user error. But, we have to find out why it doesn't happen in classic mode. james.holmlund@Eng 2001-03-12
12-03-2001