Bugzilla – Full Text Bug Listing
| Summary: | Hit count watchpoints not always re-enabled (1GLE911) | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Joe Szurszewski <eclipse> |
| Component: | Debug | Assignee: | Joe Szurszewski <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Please investigate. Please verify. Oops. The problem was a ConcurrentModificationException that was coming out of JavaBreakpoint#changeForTarget. The method was getting a List of requests, iterating over that List, and updating the requests as necessary. The trouble was that "updating" often meant replacing the request (removing it from the List and adding a new request). When iteration over the list tried to continue (after modifying the list), we were getting the exception. Fixed. JavaBreakpoint#changeForTarget now iterates over a clone of the list. Verified. |
JGS (10/10/01 1:46:12 PM) Under 203: public class InfiniteLoop { private String string = "foo"; protected int counter = 0; public static void main(String[] args) { (new InfiniteLoop()).loop(); } public void loop() { int i = 0; while (true) { System.out.println("Looping " + i + string); i++; counter++; try { Thread.sleep(1000); } catch (InterruptedException e) { } } } } - Set access watchpoint on 'string', modification watchpoint on 'counter'. - Set hit counts on both watchpoints to 2. - Debug - Both watchpoints are hit - After second watchpoint is hit, set hit count on both to 0 - Resume. Notice how only access watchpoint on 'string' is ever hit, the modification watchpoint on 'counter' is ignored.