United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6862295 JDWP threadid changes during debugging session (leading to ignored breakpoints)
JDK-6862295 : JDWP threadid changes during debugging session (leading to ignored breakpoints)

Details
Type:
Bug
Submit Date:
2009-07-20
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2009-07-30
Component:
hotspot
OS:
linux,generic,windows
Sub-Component:
jvmti
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs14,6u14
Fixed Versions:
hs14.2 (b01)

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Linux  2.6.18.5 - running in 32-bit mode, with 64-bit libraries available on the system

A DESCRIPTION OF THE PROBLEM :
The JDWP threadid of the main thread can change over the course of a debugging session in certain circumstances. From my understanding of the specification, this id should not change over the course of the debugging session. Because of this, the problem manifests as breakpoints being ignored when debugging in Eclipse. See my comments in the following Eclipse bug report for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=279137

This problem only started to occur in version 1.6.0_14. The problem does not occur in version 1.6.0_13.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
  To reproduce this problem, perform the following steps:

1) Compile the source given below
2) Run the class as so:

java -Xmx16m -classpath . -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:41010 com.test.client.Test

3) Start up jdb, and set breakpoints at the the lines with System.out.println("start") and System.out.println("end")

4) Run to the 1st breakpoint, and type "threads" - note the thread id of the main thread

5) Run to the 2nd breakpoint. You'll see the following exception printed out in jdb:

Breakpoint hit: Exception in thread "event-handler" java.lang.NullPointerException
        at com.sun.tools.example.debug.tty.TTY.printCurrentLocation(TTY.java:212)
        at com.sun.tools.example.debug.tty.TTY.vmInterrupted(TTY.java:189)
        at com.sun.tools.example.debug.tty.EventHandler.run(EventHandler.java:86)
        at java.lang.Thread.run(Thread.java:619)

6) Type "threads". Notice that the thread id of the main thread has changed!

One other interesting note - if you change the command line in step 2 to

java -Xmx16m -Xms12m -classpath . -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:41010 com.test.client.Test

and re-run the test, the problem will not occur. That is , the thread id of the main thread will remain stable throughout the debugging session, and no exception will be printed out in jdb. However, this is not a true workaround - if one were to change the following part of the source code:

System.out.println("start");
init(1000000);
System.out.println("end");

to

for (int i =0; i < 10; i++) {
  System.out.println("start");
  init(1000000);
  // SDN comment by rdayal puts the clear() call here
  // objList.clear();   
  System.out.println("end");
  // The Eclipse thread puts the clear() call here.
  // I'm going with this location since that's what I've
  // been using to repro the bug.
  objList.clear(); 
}

the problem would eventually occur. This leads me to believe that garbage collections are the culprit.



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package com.test.client;

import java.util.ArrayList;
import java.util.List;

public class Test {

        public static List<Object> objList = new ArrayList<Object>();


        private static void init(int numObjs) {
                for (int i = 0; i < numObjs; i++) {
                        objList.add(new Object());
                }
        }

        /**
         * @param args
         */
        public static void main(String[] args) {

                System.out.println("start");
                init(1000000);
                System.out.println("end");
        }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
1) Use 1.6.0_13
2) Set the -Xmx flag to a large amount of memory, and set the -Xms flag to a matching value. This is not a true workaround though - it will only delay the the first GC, at which point the problem will crop up.

Release Regression From : 6u13
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
I attached scripts to reproduce the bug:

% ksh docompile.ksh $JAVA_HOME
Compiling with:
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)


% ksh doit.ksh $JAVA_HOME
+ /java/re/jdk/1.6.0_14/latest/binaries/solaris-i586/bin/jdb
+ sleep 2
Initializing jdb ...
> + echo stop in com.test.client.Test.main
+ sleep 2
Deferring breakpoint com.test.client.Test.main.
It will be set after the class is loaded.
> + echo run -showversion -client -Xmx16m  com.test.client.Test
+ sleep 2
run  -showversion -client -Xmx16m  com.test.client.Test
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode)

Set deferred breakpoint com.test.client.Test.main

Breakpoint hit: "thread=main", com.test.client.Test.main(), line=22 bci=0

main[1] + echo stop at com.test.client.Test:23
+ sleep 2
Set breakpoint com.test.client.Test:23
main[1] + echo stop at com.test.client.Test:25
+ sleep 2
Set breakpoint com.test.client.Test:25
main[1] + cnt=0
+ [ 0 -lt 10 ]
+ echo cont
+ sleep 2
>
Breakpoint hit: "thread=main", com.test.client.Test.main(), line=23 bci=8

main[1] + echo cont
+ sleep 2
> start

Breakpoint hit: Exception in thread "event-handler" java.lang.NullPointerException
        at com.sun.tools.example.debug.tty.TTY.printCurrentLocation(TTY.java:212)
        at com.sun.tools.example.debug.tty.TTY.vmInterrupted(TTY.java:189)
        at com.sun.tools.example.debug.tty.EventHandler.run(EventHandler.java:86)
        at java.lang.Thread.run(Thread.java:619)
Attached an updated version of doit.ksh that reproduces the
failure with either the Client or Server VMs. Also added
jdb "threads" commands to document that the thread ID has
changed.

                                    

Comments
WORK AROUND

Using the option -XX:+UseParallelGC makes the failure not
reproducible with either the Client VM or the Server VM.
                                     
2009-07-20
PUBLIC COMMENTS

This bug is duplicate of a slightly older bug:

    6858776 3/3 Regression: 6u14: jdb throws NPE on Windows
                when dealing with breakpoints

6858776 is escalated, but this bug (6862295) has more analysis.
                                     
2009-07-21
EVALUATION

I've spent much of the day looking through the JVM/TI
Tag Map support code. The following *HACK* makes the
bug go away so I'm on the right track...

diff -r 8c79517a9300 src/share/vm/prims/jvmtiExport.cpp
--- a/src/share/vm/prims/jvmtiExport.cpp        Thu Jul 16 18:21:40 2009 -0700
+++ b/src/share/vm/prims/jvmtiExport.cpp        Wed Jul 22 17:49:30 2009 -0600
@@ -2471,6 +2471,7 @@
  }

  // Notify heap/object tagging support
-  JvmtiTagMap::gc_epilogue(_full);
+  //JvmtiTagMap::gc_epilogue(_full);
+  JvmtiTagMap::gc_epilogue(true);
}
#endif // JVMTI_KERNEL

Thanks to Alan B. for providing useful tracing hints.

Discussions with Ramki revealed that the logic that
controlled the setting of variable "_full" was modified
as part of the initial G1 putback. The short comings
of the "was there a full GC?" logic are encapsulated
by bug 6470420.
                                     
2009-07-23
SUGGESTED FIX

See attached 6862295-webrev-cr0.tgz for the proposed fix.
                                     
2009-07-28
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589
                                     
2009-07-29
PUBLIC COMMENTS

Closing the loop on a few loose ends. I've been able
to reproduce this bug with the following GC options:

    -XX:+UseSerialGC -Xmx32m
    -XX:+UseConcMarkSweepGC -Xmx32m
    -Xconcgc -Xmx32m
    -Xincgc -Xmx32m

using both Client and Server VM product bits. The "-Xincgc"
failure is intermittent.

The bug did not reproduce with the following GC options:

    -XX:+UseParallelGC -Xmx32m
    -XX:+UseParallelOldGC -Xmx32m

using both Client and Server VM product bits.
                                     
2009-08-03
EVALUATION

The test for this bug BreakpointWithFullGC.sh has been pushed:

    http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0182203084a

This is an SDK/JDK format test in the JDI_REGRESSION testsuite:

    com/sun/jdi/BreakpointWithFullGC.sh
                                     
2009-09-15



Hardware and Software, Engineered to Work Together