Community
Participate
Working Groups
Build id: I20060413-0010. The two (faulty) test cases suggested in comment #6 of bug 86813 can be reproduced. They were contributed by Stefano Rocca and are copied here for convenience. TEST A public class Bug_86813a { public static void main(String[] args) { int x = -1; // 1. breakpoint here try { int i = 4; switch (i) { case 1: x = 3; break; case 2: x = 4; // 2. jumps here break; // does not step here default: } } catch (Exception e) { } System.out.println(x); // 3. jumps here System.exit(0); } } The empty default statement does not resolve the problem. TEST B public class Bug_86813b { public static void main(String[] args) { int x = -1; // 1. breakpoint here try { int i = 4; switch (i) { case 1: x = 3; break; case 2: x = 4; break; // 2. jumps here default: break; // does not step here } } catch (Exception e) { } System.out.println(x); // 3. jumps here System.exit(0); } } The default statement is apparently ignored
The problem comes from the optimized goto to the next bytecode. Removing the goto also removes the entry in the line table.
Created attachment 38975 [details] Proposed fix Maxime, Could you please try this patch? I believe it improves the debug experience.
Philippe, RC2 candidate ?
Created attachment 38980 [details] Better patch
Created attachment 38993 [details] Regression test Update the test case for bug 86813 (SwitchTest.test12)
(In reply to comment #2) > Created an attachment (id=38975) [edit] > Proposed fix > > Maxime, > > Could you please try this patch? I believe it improves the debug experience. > Trying with your latest patch, I get something better, but still a bit odd. Taking TEST A case, I jump from the switch line to the second break line (instead of the default line). Is it the behavior you get ?
I am not seeing how a change in ForeachStatement (see patch) is indicated here... I have the feel all introduced branch bytecodes (jump to natural try exit, jump over if-else, etc...) are going to exhibit same behavior. Growing the last entry is simply not the answer in case it is not on the execution path (like here with switch scenario).
Same issue with enclosing IF: public class X { public static void main(String[] args) { int x = -1; // 1. breakpoint here if (args != null) { int i = 4; switch (i) { case 1: x = 3; break; case 2: x = 4; // 2. jumps here break; // does not step here default: } } else { x = 5; } System.out.println(x); // 3. jumps here } }
I'd be enclined to defer post 3.2 (i.e. not worse than it was in 3.1, and a bit late to worry about)
> Trying with your latest patch, I get something better, but still a bit odd. > Taking TEST A case, I jump from the switch line to the second break line > (instead of the default line). Is it the behavior you get ? In the first case, the line with the default doesn't generate anything so the previous break statement is the best option.
(In reply to comment #7) > I am not seeing how a change in ForeachStatement (see patch) is indicated > here... This change is to be sure that no entry is added when no code has been generated since last entry. It prevents a method call. > I have the feel all introduced branch bytecodes (jump to natural try exit, jump > over if-else, etc...) are going to exhibit same behavior. Growing the last > entry is simply not the answer in case it is not on the execution path (like > here with switch scenario). I don't grow the last entry. I simply readjust its line number if required.
Closing as LATER.
(In reply to comment #8) > Same issue with enclosing IF: The patch also handles this case. Since the default doesn't generate any code, the previous break is used. If there is no break, we then end up with the same line as today. We might want to associate the jump to the source end of the switch statement.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
