Bugzilla – Full Text Bug Listing
| Summary: | Variable is not updated in the variables view | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ed Willink <ed> | ||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | darin.eclipse, johannes_rieken | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
M6 This seems to be getting worse. I now get missing lines from the variables view, that appear if the view is toggled to breakpoints and back again. Ping. Any comment? Still an intermittent problem on 3.4.1. *** This bug has been marked as a duplicate of bug 200364 *** |
Created attachment 85859 [details] Bad variables view display Reraising 82850 as requested in #49. I continue to see intermittent failures of the variables view to reflect the true state of a variable. Currently problem is still there on 3.4M4. The attached demonstrates a remarkably interesting string value for a null variable. Approximate prior user behaviour: Run JUnit test. Advance to breakpoint 4 times. Then while suspended progressively click down (visually) the stack frame. Happen to notice a garbage display. NB. This problem is highly intermittent. Perhaps about 1% of displays are wrong. Clicking on breakpoints view then returning to variables view corrects display. I have tried to reproduce since the JUnit test is easy to rerun. No success. But, a possible insight. Why is line 4 highlighted? I don't think I explicitly selected that line, so it's a residue of an earlier operation. While trying to reproduce, I am slightly baffled by the seemingly arbitrary choice as to which, if any, line in the variables view is to be selected. Maybe this 'arbitrary' choice has an associated race condition. Possibly related to the above insight, I now recall another irritating behaviour. When repeatedly advancing to the same breakpoint, the bottom of the variables view usually updates to show the toString() of the same (useful) element, but occasionally loses it, requiring a re-selection.