Bug 279137 - Breakpoints fail to hit under JDK 1.6.0_14
Summary: Breakpoints fail to hit under JDK 1.6.0_14
Status: RESOLVED NOT_ECLIPSE
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.4.2   Edit
Hardware: PC Windows XP
: P3 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-Debug-Inbox CLA Friend
QA Contact:
URL:
Whiteboard:
Keywords: readme
: 286512 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-06-04 13:18 EDT by Jim Goodwin CLA Friend
Modified: 2011-03-24 02:36 EDT (History)
28 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Goodwin CLA Friend 2009-06-04 13:18:47 EDT
I have a problem with breakpoints not being hit.

The problem seems to involve some state somewhere getting
fouled, and then the breakpoints miss until I kill the
process and clean all projects.

I have no idea how to reproduce the broken condition.
It happens frequently however, sometimes multiple times a day.

The breakpoints that miss appear to be always on the Swing
event processing thread. Breakpoints in my own worker threads
still seem to hit ok.

The breakpoints are plain vanilla line breakpoints, created by
clicking on the left gutter. They show the blue ball with the
black checkmark. They are set at lines with a System.out.print,
so I know they are being passed. 

I have focussed on breakpoings set in my own code, on listeners 
and such, rather than in library code, to rule out confusions
that arise when source code attachements to libraries get loused
up. However, I think I have observed the same problem with 
breakpoints set in the JRE or the JFreeChart library I am using.


While my app is running and missing breakpoints, one can 
remove and reinstall the breakpoints, or disable and reenable
them, and it has no effect, they continue to miss.

Here is the really confusing bit: I had my app running, let us
call that invocation A, and it was missing breakpoints on the
swing threads. I ran another invocation B, and it hit the
breakpoints ok. But if I kill both and restart, call that one
invocation C, C was still hosed. So the scope of the fouled
state is unclear. Maybe it always belongs to the topmost
invocation in the debugger window. Seems like a stretch,
but I have no better theory.


This is on Windows XP Pro, SP 3, Eclipse Version: 3.4.2
Build id: M20090211-1700. The JRE used by my projects is
jdk1.6.0_14.

I believe I observed this on jdk1.6.0_05 as well but have
not yet systematically tested different versions. This all
started happening lately when I upgraded both Eclipse and
Java from 3.3 and 1.5 respectively.


Jim Goodwin
Comment 1 Dani Megert CLA Friend 2009-06-05 03:29:09 EDT
Is there anything in the .log or console?
Comment 2 Oliver Masutti CLA Friend 2009-06-05 03:45:20 EDT
(In reply to comment #1)
> Is there anything in the .log or console?
 
nothing here. The problem seems to be related to release 1.6.0_14. After reverting to 1.6.0_13, all breakpoints are hit properly again. Hence I assume a JDK, not an Eclipse issue.
Comment 3 Jim Goodwin CLA Friend 2009-06-05 08:18:43 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Is there anything in the .log or console?
> 
Nothing here either. I was having the problem yesterday 6/4
and there are no log entries at all for that day.

By console I assume you mean the familiar place where
System.out and .err output appear; no, I never saw
anything there.

/jim
Comment 4 Darin Wright CLA Friend 2009-06-05 09:55:19 EDT
Jim, can you see if the problem happens when using 1.6.0_13? 
Comment 5 Jim Goodwin CLA Friend 2009-06-05 10:00:37 EDT
(In reply to comment #4)
> Jim, can you see if the problem happens when using 1.6.0_13? 
> 

I'll try. It may take a day or two before the outcome is obvious
(since I can't make it happen on demand).

/jim
Comment 6 Rajeev Dayal CLA Friend 2009-06-05 11:03:20 EDT
We are running into the exact same problem (not hitting breakpoints) when attempting to debug a GWT application. GWT does not use Swing, but it does make use of SWT. The problem is consistently reproducible - the breakpoints are always missed.

Moreover, this issue occurs when using JDK 1.6.0_14, but not with JDK 1.6.0_13. 

I've tried launching a debugging session with GWT using IntelliJ, and the same problem does not occur - that is, debugging works fine in JDK 1.6.0_14.
Comment 7 Rajeev Dayal CLA Friend 2009-06-05 17:39:53 EDT
Ok, so I did more research into this problem by debugging a simple "Hello World" GWT App.

When launching the debug configuration in Eclipse, one of the first things that Eclipse does is creates a JDIDebugTarget instance. When initializing this instance, it queries the debugee for its threads, and then stores information about them in the JDIDebugTarget instance. One of the threads that it stores information about is obviously the main thread, which had a JDWP threadId (not the same as the java.lang.Thread id) of "1".

Later on, when a breakpoint is hit, the debugger receives information from the debugee about which thread the breakpoint occurred in. The thread is again identified by the JDWP threadId. However, in this case the id returned for the main thread id "43"! So, when the debugger attempts to find this thread in it's list of known threads via the JDIDebugTarget (see JavaBreakpoint.handleEvent()), it fails to do so, so it ignores the breakpoint.

So, the only way that I can tie all of this together is to say that:

-GWT, which uses SWT, somehow causes the JWDP threadId representing the main thread to change. I'm suspecting SWT here, but I can't conclusively say that SWT is the cause. I just know that in a normal Java project, all of the breakpoints are hit. The other thing that GWT does is fire up some additional threads (for update checking and all) - that may also have something to do with it. The simple programs I was creating to test this in a pure Java project did not have threads.

-The implementation of the JDK has changed in some fashion that causes the JDWP threadid to vary (since there is no way that the main thread could have somehow been re-created) - when using JDK 1.6.0_13, the JDWP threadId for the main thread remained stable at a value of "1". I'm not sure if this is a bug on their side or not - I'd expect that this id would be stable (how else would the debugger keep track of the thread view in its UI)

-Eclipse's debugging implementation relies on the fact that the JDWP threadid for a given thread will remain stable throughout the debugging session. This seems like a reasonable assumption, but maybe it's not for some reason? IntelliJ is not hitting this problem.

As an aside, I was still able to hit the "pause" button in the debugger and pause the main thread. If it is the case that there is a mismatch between JDWP threadIds, how is this even possible?
Comment 8 Dani Megert CLA Friend 2009-06-08 04:35:33 EDT
Jim or Rajeev, can you also reproduce with a (simple) Swing app? Using a simple frame with a JTextArea worked for me.
Comment 9 Jim Goodwin CLA Friend 2009-06-08 08:47:15 EDT
(In reply to comment #8)
> Jim or Rajeev, can you also reproduce with a (simple) Swing app? Using a simple
> frame with a JTextArea worked for me.
> 

No, I can't. Sigh.

First, I never observed it except in my full messy development
context. I did try to make it happens on a smaller app. I even
tried that while my regular app was still running and in the
hosed state.  No luck.

Second - and I blush to report this:

I had some kind of big compiler-compliance configuration screwup.

So I have to assume the breakpoint issues were collateral damage from
the settings screwups. Right now things are working. If you have anything
specific you'd like me to check or look at let me know. I did make a
complete zipfile copy of the workspace at one point, so I might be able
to answer questions like "Did you have xxx set wrong?" provided you know
where on the disk to find the setting.

Otherwise, unless some problem recurs, it doesn't look practical to 
pursue  further. Sigh.

What happened was this. I had created a fresh, from-scratch install
of Eclipse, and copied my source files over on the disk and imported 
them. I may have exported/imported preferences too; I actually don't
recall. Then I worked for a week or two, during which I had the break
point problems, but never any hint of compiler-compliance issues.
During that time, Eclipse got restarted many times, but not my PC. 

Then I rebooted the PC to install a mouse. Upon re-entering Eclipse,
I had 649 problems, all of which evidently had to do with compiler
compliance. Some complained about versions as old as java 1.3.
They involved generic classes, use of the identifier "assert", casts
that used to be illegal and are ok now, all sorts of such stuff.
It was acting like my settings were 1.0 or something.

I had not had any such problems in my old install. I checked all the settings
I could find, rummaged about in the XML files on the disk and so forth.
Everything was set to 1.6 consistently except for one thing:

At Preferences -> Java -> Compiler, "Compiler compliance level" was 1.6, 
and the checkbox "Use default compliance settings" was checked (all ok).
Under that, "Generated .class files compatibility" and "Source compatibility"
were grayed out, but their settings are still shown, and they were wrong:
1.3 and 1.4 or vice-versa. That was the only anomaly I found.

I unchecked "Use default compliance settings", set them properly, and
then rechecked "Use default compliance settings". They showed 1.6 grayed
out then, but the Problems remained (after clean all), and upon re-entering 
Preferences, they had reverted back to 1.4 and 1.3.

I thrashed a lot. What finally worked was something like this: setting
all projects to use project specific settings (all at 1.6), clean all.
Then go back to using global settings and clean all. Exit and restart
Eclipse randomly. Rinse and repeat.

Finally the errors went away, and since then I have not observed any
breakpoint failures either, at least so far. 


Jim

Comment 10 Rajeev Dayal CLA Friend 2009-06-08 20:23:24 EDT
I was unable to reproduce this with a simple swing app. Can you post your code, and I can test and see if I run into the same problems on my machine?

(In reply to comment #8)
> Jim or Rajeev, can you also reproduce with a (simple) Swing app? Using a simple
> frame with a JTextArea worked for me.
> 

Comment 11 Dani Megert CLA Friend 2009-06-09 04:25:41 EDT
> Can you post your code,
Sure, here it is:

public class TextAreaCode {
	public static void main(String[] args) {
		JFrame jFrame= new JFrame();
		JPanel jPanel= new JPanel();
		JTextArea text= new JTextArea(2, 40);
		jFrame.add(jPanel);
		jPanel.add(text);
		jFrame.setSize(500, 100);
		jFrame.setVisible(true);
		jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
	}
}


I also tried various examples from jdk6_14\demo\jfc
Comment 12 Rajeev Dayal CLA Friend 2009-06-09 10:21:08 EDT
Ok, working with another developer, I've got a repro case that does not involve Swing/AWT/GWT. Given the following code:

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");
	}
}

Set breakpoints at the lines with the System.out.printlns. Now, if you run this example in Eclipse in debug mode, with "-Xmx16m" as the VM arguments, then the breakpoint will be hit on the "start" line, but when you resume the program, the breakpoint will NOT be hit on the "end" line.

However, if you modify the VM arguments to be "-Xmx16m -Xms12m", then both breakpoints will be hit.

I tried to reproduce this behavior with JDK 1.6.0_13, but I was not able to do so. That is, in all cases, all of the breakpoints were hit.

So, I guess it is still debatable as to whether or not this is a Eclipse or JDK bug. While it does seem incorrect that the JDWP thread id for the main thread changes, Eclipse's implementation's reliance on this is the cause of the problem. 

I'm going to file a bug in Sun's bug database and cross-reference this bug report. 
Comment 13 Darin Wright CLA Friend 2009-06-09 12:19:17 EDT
I can reproduce the problem with the test case in comment#12. Thanks.

Here's the trace of events showing the changing thread ID (from 1 to 15).

{VMStartEvent: 0}
{ThreadStartEvent: 3}
{ClassPrepareEvent: 17, ClassPrepareEvent: 15}
{BreakpointEvent: 23 Thread: java.lang.Thread (name=main, id=1)}
{BreakpointEvent: 22 Thread: java.lang.Thread (name=main, id=15)}
{ThreadDeathEvent: 4}
{ThreadStartEvent: 3}
{ThreadDeathEvent: 4}
{VMDisconnectEvent: 0}

The JDWP spec (http://java.sun.com/javase/6/docs/technotes/guides/jpda/jdwp-spec.html) for thread ID claims:

"Uniquely identifies an object in the target VM that is known to be a thread". 

Then object ID claims:

"Uniquely identifies an object in the target VM. A particular object will be identified by exactly one objectID in JDWP commands and replies throughout its lifetime (or until the objectID is explicitly disposed). An ObjectID is not reused to identify a different object unless it has been explicitly disposed, regardless of whether the referenced object has been garbage collected. An objectID of 0 represents a null object."

Based on this, I would not expect the thread ID to change for the same thread object.

Comment 14 Rajeev Dayal CLA Friend 2009-06-09 13:53:38 EDT
Great. As an FYI, here is some more information that I discovered:

1) The workaround of setting -Xms8m is not really a workaround at all - if you modify the test case by taking the following lines:

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

and changing them to:

for (int i = 0; i < 10; i++) {
  System.out.println("start");            
  init(1000000);
  System.out.println("end");
  objList.clear();
}

the problem will occur after about 5 iterations of the main loop. So, it seems that GCs are the culprit.

2) I was able to reproduce this problem using jdb, which definitely rules out Eclipse as being the source of the problem. Not only is the thread change visible using jdb, but an NPE is thrown within jdb's code, probably due to the threadid switch.

I've logged a bug with Sun, but it's pending approval. Once it gets approved, I'll post the URL here.

Not sure if you want to close this out, now that we know this is not an Eclipse problem, or if you want to leave it open while the Java guys investigate.





Comment 15 Darin Wright CLA Friend 2009-06-09 13:59:37 EDT
Marking as NOT_ECLIPSE, but adding the readme tag for those interested. Please update with the Sun bug reference once you have it.

Thanks to all.
Comment 16 Markus Keller CLA Friend 2009-06-10 06:33:33 EDT
> Marking as NOT_ECLIPSE, but adding the readme tag for those interested.

Could you also add this to the Readme file (bug 274675), as first item in the JDT section? JDK 1.6.0_14 is the latest available release and we even list it as "Reference Platform", though it's really unusable for debugging.

I would even go as far as turning the reference platform back to JDK 1.6.0_13 because of this, since Java debugging is a central feature of the SDK.
Comment 17 Markus Keller CLA Friend 2009-06-10 06:45:10 EDT
Oops, Dani pointed out that JDK 1.6.0_14 is *not* the reference platform.
Sorry for the confusion. But a readme entry would still be worthwhile.
Comment 18 Darin Wright CLA Friend 2009-06-10 09:05:43 EDT
Not sure we want to spin another build just for this. If another build is done, we can have add a readme (but there's always going to be one more...).
Comment 19 Dani Megert CLA Friend 2009-06-10 09:27:50 EDT
>Not sure we want to spin another build just for this. 
We should not rebuild just for that but we should update the read me now, so that it is in place in case another build happens.
Comment 20 Michael Rennie CLA Friend 2009-06-10 12:01:13 EDT
Also confirmed the problem in Linux (Ubuntu Jaunty 9.04). Using the steps in comment #12 - the second breakpoint is never hit using 1.6 update 14, but works fine using 1.6 update 13.
Comment 21 Darin Wright CLA Friend 2009-06-10 12:19:51 EDT
(In reply to comment #14)
> I've logged a bug with Sun, but it's pending approval. Once it gets approved,
> I'll post the URL here.

Just wondering if the associated Sun bug is available yet?
Comment 22 Rajeev Dayal CLA Friend 2009-06-10 12:57:05 EDT
Interestingly enough, no! I wonder if the turnaround normally takes this long..
Comment 23 Mauro Molinari CLA Friend 2009-06-10 14:53:43 EDT
(In reply to comment #22)
> Interestingly enough, no! I wonder if the turnaround normally takes this long..

Yes, it does... :-(
Comment 24 Tom CLA Friend 2009-06-18 07:36:26 EDT
Hi,

I experienced the same issue with Eclipse 3.4.2 and JDK 1.6.0_14. I was using the experimental new G1, and was able to use a workaround by removing the following startup properties in my eclipse.ini config file:
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC

Hope this may help,
Thomas
Comment 25 David Karnok CLA Friend 2009-06-22 09:08:04 EDT
Same trouble with Java 7 build 59.
Comment 26 Spamdunur CLA Friend 2009-07-01 03:45:05 EDT
(In reply to comment #14)

Any news from Sun?

Thx
Comment 27 Rajeev Dayal CLA Friend 2009-07-07 13:36:52 EDT
I have not heard anything from Sun. I wrote them again, asking them about this issue, but I have not received a reply as yet. It has been over a month now - I may just create a new bug report and re-file this issue.
Comment 28 David Karnok CLA Friend 2009-07-07 15:06:49 EDT
(In reply to comment #27)
> I have not heard anything from Sun. I wrote them again, asking them about this
> issue, but I have not received a reply as yet. It has been over a month now - I
> may just create a new bug report and re-file this issue.

This february I submitted two j2d bug. It took Sun 6 weeks to acknowledge and 4 weeks to be available in public bug database.
Comment 29 Karl Pietrzak CLA Friend 2009-07-07 15:20:01 EDT
(In reply to comment #14)
> Great. As an FYI, here is some more information that I discovered:
> 
> 1) The workaround of setting -Xms8m is not really a workaround at all - if you
> modify the test case by taking the following lines:
> 
> System.out.println("start");            
> init(1000000);
> System.out.println("end");
> 
> and changing them to:
> 
> for (int i = 0; i < 10; i++) {
>   System.out.println("start");            
>   init(1000000);
>   System.out.println("end");
>   objList.clear();
> }
> 
> the problem will occur after about 5 iterations of the main loop. So, it seems
> that GCs are the culprit.

I am just writing Eclipse user writing to confirm this problem after another developer on our team bumped into this problem.

In the above example, I set my breakpoint on the S.o.p("start"), and my breakpoint was only hit -once-.

This is Java 6u14, Windows XP, Eclipse 20090621-0832. 

POSSIBLE WORKAROUND:
For me, adding the "-server" JVM argument seems to have helped.  It stopped for me 10 times in the above example.  Still need to do more testing to figure out whether "-server" is THE workaround.
Comment 30 Karl Pietrzak CLA Friend 2009-07-07 15:24:44 EDT
From the JDK 6u14 release notes:
BUG FIXES:
6498878 	hotspot 	compiler1 	client compiler crashes on windows when dealing with breakpoint instructions 

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6498878

Not sure if the two are related.  Just food for thought.
Comment 31 Gary Gregory CLA Friend 2009-07-08 14:35:57 EDT
I wonder if the same bug shows up in NetBeans... that might light a fire under Sun ;)
Comment 32 David Williams CLA Friend 2009-07-08 15:16:34 EDT
(In reply to comment #29)
> (In reply to comment #14)
> 
> In the above example, I set my breakpoint on the S.o.p("start"), and my
> breakpoint was only hit -once-.
> 
> This is Java 6u14, Windows XP, Eclipse 20090621-0832. 
> 

Breakpoint hit only once? Do you have IE 8 installed? There's a similar breaks-only-once issue I reported while debugging JSPs, see bug 279195, that appeared related to having IE 8 installed. Maybe a coincidence? 
Comment 33 Rajeev Dayal CLA Friend 2009-07-09 10:17:40 EDT
Tom's workaround sounds reasonable to me, though I haven't tried it.

In terms of using the "-server" option, I'm not sure if this even does anything in JDK 6. I think that the server VM is now the default. The number of times the breakpoint will be hit seems to be a function of when a GC occurs, which in itself is determined by the heap size that you set for the VM.

As for the same bug showing up in NetBeans, that's a good question. However, if you use jdb (Sun's own command-line debugger that comes with the JDK), this problem does occur, so that should definitely have lit a fire under them :). It's definitely an issue on their side.
Comment 34 Ismael Juma CLA Friend 2009-07-09 10:20:42 EDT
(In reply to comment #33)
> Tom's workaround sounds reasonable to me, though I haven't tried it.
> 
> In terms of using the "-server" option, I'm not sure if this even does anything
> in JDK 6. I think that the server VM is now the default.

It's only the default if your machine is "server-class" or you're using a 64-bit JVM. What constitutes "server class" depends on many factors:

http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
Comment 35 Karl Pietrzak CLA Friend 2009-07-09 10:42:31 EDT
(In reply to comment #34)

> It's only the default if your machine is "server-class" or you're using a
> 64-bit JVM. What constitutes "server class" depends on many factors:
> 
> http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
 
Ismael is right on.  On my Windows XP box:

H:\>"c:\Program Files\Java\jdk1.6.0_14\bin\java.exe" -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)

H:\>"c:\Program Files\Java\jdk1.6.0_14\bin\java.exe" -server -version
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)

H:\>


I pointed to the JDK because that's what I have my Eclipse set to point to.
Comment 36 Rajeev Dayal CLA Friend 2009-07-13 11:31:37 EDT
Ah, I stand corrected.

Based on my earlier experiments, it seems that the number of times the breakpoint is hit depends on the heap size, and in the case of the server runtime, the heap sizes are larger.

Also, a different collector is used on server-class machines (the throughput collector, I believe). Perhaps this problem only exists in the serial collector (a total shot in the dark, but Tom's workaround involved using the G1 Garbage Collector, as opposed to the serial GC).
Comment 37 Olivier Thomann CLA Friend 2009-07-17 15:14:00 EDT
JDK6_15 doesn't seem to work either. Sometimes the breakpoints are hit, sometimes now. Very frustrating!
Comment 38 Mauro Molinari CLA Friend 2009-07-17 20:23:20 EDT
(In reply to comment #37)
> JDK6_15 doesn't seem to work either. Sometimes the breakpoints are hit,
> sometimes now. Very frustrating!

Where did you find JDK6_15? On Sun's website the latest version I see is 6_u14...
Comment 39 Spamdunur CLA Friend 2009-07-20 10:28:26 EDT
(In reply to comment #27)
> I have not heard anything from Sun. I wrote them again, asking them about this
> issue, but I have not received a reply as yet. It has been over a month now - I
> may just create a new bug report and re-file this issue.

Rajeev, would you please re-submit it? 

Thx
EH
Comment 40 Ismael Juma CLA Friend 2009-07-20 10:34:31 EDT
Re-submitting is not the most effective way to go about this. Post about this problem in the OpenJDK mailing lists with the review id and someone may be able to help. There are some people on #openjdk that can also help at times.
Comment 41 Rajeev Dayal CLA Friend 2009-07-20 11:42:02 EDT
Ok, I'll try the avenues suggested by Ismael. I'll report back my findings later today.
Comment 42 Karl Pietrzak CLA Friend 2009-07-20 11:46:22 EDT
(In reply to comment #41)
> Ok, I'll try the avenues suggested by Ismael. I'll report back my findings
> later today.

Rajeev: I'm watching the jdk6 mailing list (http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev), so I'll back you up when you post with examples, etc.
Comment 43 Karl Pietrzak CLA Friend 2009-07-20 11:54:02 EDT
(In reply to comment #41)
> Ok, I'll try the avenues suggested by Ismael. I'll report back my findings
> later today.

Oh, BTW, I found the change to the jdk6 branch that may be relevant to this:

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/annotate/1f530c629c7d/src/share/vm/ci/ciMethod.cpp

6498878: client compiler crashes on windows when dealing with breakpoint instructions
Summary: _is_compilable check prevents breakpoint bytecodes reversion when loading bytecodes for ciMethod.
Reviewed-by: never 
Comment 44 Rajeev Dayal CLA Friend 2009-07-20 12:49:31 EDT
Well, well, well! The bug was acknowledged today! Here is the link:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

You can't see the bug yet though - I think it might take a day for it to be
visible in the external database.

Do you guys think I should still post on the OpenJDK list, or is this
sufficient?
Comment 45 wormwood CLA Friend 2009-07-21 10:50:56 EDT
The bug is now visible: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

We have listed a workaround for this problem, which can be used while we investigate a fix for the bug. 

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

I would recommend that you use the 'watch this bug' feature, so you can be notified when there are updates to the bug. Here is the link to watch this specific bug: http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6862295 (you will be asked to log in)

-Roger
Comment 46 Dani Megert CLA Friend 2009-07-30 05:21:11 EDT
Updated readme with suggested workaround from comment 45.
Comment 47 Karl Pietrzak CLA Friend 2009-07-30 11:02:15 EDT
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

Looks like a fix is imminent!

Bug ID:   	 6862295
Votes 	25
Synopsis 	JDWP threadid changes during debugging session (leading to ignored breakpoints)
State 	7-Fix in Progress, bug
Priority: 	2-High

Hopefully will make it to 6u16.
Comment 48 Spamdunur CLA Friend 2009-08-13 10:58:09 EDT
6u16 is ready for most OS

see
http://java.sun.com/javase/downloads/index.jsp

and

http://java.sun.com/javase/6/webnotes/6u16.html
Comment 49 Darin Wright CLA Friend 2009-08-14 09:54:01 EDT
*** Bug 286512 has been marked as a duplicate of this bug. ***
Comment 50 mohammad norouzi CLA Friend 2011-03-24 01:51:19 EDT
I updated my JDK to 1.6.0_24 but I still have the same problem!

What the strange is that breakpoints in other eclipse projects work fine and I have problem with only one of my projects.

There is no project specific settings for this one, I copied my eclipse.ini here, can you help me on this please:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vm
C:\tools\java\jdk1.6.0_24\jre\bin\client\jvm.dll
-Xms64m
-Xmx1024m
-XX:+UseParallelGC
-Dsun.lang.ClassLoader.allowArraySyntax=true
-Dosgi.requiredJavaVersion=1.5
Comment 51 Dani Megert CLA Friend 2011-03-24 02:36:13 EDT
(In reply to comment #50)
> I updated my JDK to 1.6.0_24 but I still have the same problem!
> 
> What the strange is that breakpoints in other eclipse projects work fine and I
> have problem with only one of my projects.
Please file a new bug report to track this new issue.