Bugzilla – Full Text Bug Listing
| Summary: | [compiler] Breakpoints set on break statements are never hit | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Paul Cowan <cowan> |
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.3 | ||
| Target Milestone: | 3.3 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
The problem for us is that the break doesn't end up generating any bytecode since it would be a goto to the next bytecode. So we optimize it out and therefore there is no position to reach. Philippe, I don't see how we can get a line entry for the break statement if we optimize it out. I don't think we would de-optimize the compiler to address this scenario. No action planned. Closing as Won't fix. |
Build ID: I20070222-0951 Steps To Reproduce: 1. Create a new class with the following code: public static void main(String[] args) { int i = 0; while (true) { i++; if (i == 1000) { System.out.println("Breaking"); // *A* break; // *B* } } System.out.println("Broken"); // *C* } 2. Set breakpoints on the lines marked *B* and *C* 3. Debug the class; only the breakpoint at line *C* will be hit 4. If a breakpoint is added at line *A*, that will be hit. It is only the break statement itself where the breakpoint fails to be triggered. This could obviously make it difficult to debug some loops, where adding an additional 'dummy' statement (like *A* above) may not be an option (e.g. debugging a remote application).