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  customer , and type "threads" - note the thread id of the main thread

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

 customer  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.
Posted Date : 2009-07-22 14:06:21.0

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)
Posted Date : 2009-07-20 20:10:49.0

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.
Posted Date : 2009-07-20 23:03:39.0

Using the option -XX:+UseParallelGC makes the failure not
reproducible with either the Client VM or the Server VM.

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.
Posted Date : 2009-07-23 02:08:18.0

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2b4230d1e589
Posted Date : 2009-07-29 05:00:27.0

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
Posted Date : 2009-09-15 01:41:51.0

Same trouble on Windows XP (SP3)

Also same problem on Windows XP (SP2).

Perhaps this is related to Bug 6498878? (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498878)

This bug is listed as being fixed in the 6u14 release notes.  Just food for thought.

Using the server VM (via the '-server' flag) on Windows XP (SP2) -seems- to make the problem go away.  (At least makes the debugger work properly for me in Eclipse)

Since the server VM enables the ParallelGC, this observation coincides with the posted Workaround.

Hope that's helpful!

Just wanted to mention that there is a mistake in the example to re-create the problem with a higher heap. It should read as follows:

...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);
  objList.clear();
  System.out.println("end");
}

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

This has been driving our team crazy since we upgraded from u13 to u14.

Not fixed in 6_u15 as far as I can tell!

Still annoying under Windows XP SP3 32bit + Java 1.6_u15.
That said sometimes it works, sometimes not.
Using -XX:+UseParallelGC seems to work properly .

Bug report of jre 6u16:
tomcat 6.0.20 + jre 6u14,then "jre 6u16" is installed,restart computer,"Apache Tomcate" service is can't started.
then,cmd->java -version,jvm is error occured.

I can confirm the same issue exists for 1.6.0_15.

I am also having problems, but ruiing a Java ME emulator. But the strange thing is that there are breakpoints that are ignored and others not.

When I see the breakpoint details, the information of the class for a breakpoint that works is:

pkg1.pkg2.classA

But the details of the class for a breakpoint that is ignored is:

pkg1.pkg3.classB$classB

It seems that only breakponts in classes with $ are ignored. By the way, can somebody tellme why some classes have $ and others not. I think it is because som other classes are defined dynamically in the same class code, but not so sure.

This bug seems pretty important since the normal development/deploy cycle involved first developing code on a particular JDK/JRE and then deploying on the same version.

If I cannot develop with update 14 or above, my company is not going to deploy on update 14 or above.  I would assume that this is the same for many companies.

Please fix this bug soon!