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.