Community
Participate
Working Groups
I20070327-0800 I just came across a situation where my debugged process would just take forever to run... This is on a process that normally takes only a few minutes to complete. The steps to reproduce are a but tedious however I think it worth investigating because the problem can be reproduced with both an IBM VM 1.5 and a JDK 1.6. Here are the steps: - load the org.eclipse.equinox.prov.releng project from the equinox-incubator/provisioning project. - import the projectSet.psf file - then follow more instructions in the "HOW TO RUN.txt" at the root of the org.eclipse.equinox.releng project. Before going on the step 2 from the previous file. Add a breakpoint on line 48 of file InstallRegistry (the content of the line is "public void notify(EventObject o) {"). You will see that the application is just horribly slow to run. Given the number of steps, let me know if you need any help reproducing the problem.
Please note that method entry/exit breakpoints put the VM in trace mode which can be very slow. Please try a line breakpoint on the first line of the method (if possible) to avoid this.
The location in question was a method of an anonymous inner type. In this case we revert to method entry requests, which slows the VM down. However, when I tested a method entry breakpoint on an anonymous inner type - it was never hit. It looks like they are not working in this case: package a.b.c; public class SomeClass { public static void main(String[] args) { new SomeClass().go(); } public void go() { Runnable r = new Runnable(){ >>> BP <<< public void run() { System.out.println("RUNNING"); } }; r.run(); } }
This is a more complex problem than I initially thought. The root problem is that each compiler can provide the type name for the anonymous classes differently, and therefore we cannot easily deduce what type to place the method breakpoint on (this also fails for watchpoints as well). If we have an anonymous type inside another, any given compiler could compile the anonymous types in a different way. For example, the Eclipse compiler creates two class files for nested anonymous types as <typename>$1.class and <typename>$2.class, whereas javac creates <typename>$1.class and <typename>$1$1.class. Example inner anonymous: package a.b.c; public class SomeClass { public static void main(String[] args) { new SomeClass().go(); } public void go() { Runnable r = new Runnable(){ Runnable innerun = new Runnable() { Object o = null; public void run() { System.out.println(o); } }; public void run() { innerun.run(); } }; r.run(); } } Therefore the most restrictive pattern for the breakpoint request could be something like <typename>$*, which would cause us to end up searching every single anonymous inner type (possibly before the one want) to determine if we should be stopping there. If we also consider that method breakpoints put the VM in tracing mode, this gets even worse... The immediate solution is to use a line breakpoint on the first line of the method, until we can figure what we are going to do. Watchpoints are just hosed, there is no workaround for them.
*** Bug 176762 has been marked as a duplicate of this bug. ***
Not planned for 3.3
Interesting observations. I'd almost given up expecting method breakpoints to work on Sun JVM in 3.4M6, now I understand why. I may now deliberately avoid method breakpoints altogether for performance reasons. It would be really good to provide an obvious warning to the user that method breakpoints are crippling. (Perhaps a strongly coloured banner line at the top of the stack trace.) I've been mentally blaming a much degraded Eclipse Platform/EMF/OCL/myself. It no doubt explains why exiting from a debug session under debug can take 5 minutes! Perhaps there should be pseudo-method breakpoints that are actually line breakpoints that accurately track the entry/exit line.
This is a major bug and can cause lots of wasted time. If we can't fix this then we must at least not allow to add such breakpoints in the first place.
I just hit this again. I tried to set an execution breakpoint on: default public String getName() { return "Please set the name of your bx tool!"; } Unfortunately since this is one line. I got an entry breakpoint and a totally unuseable debugger. And worse, even after I cleared the breakpoint, I inflicted a StackOverflowError on myself and so had to kill Eclipse since StackOverflowError is another meg-debugger failing. Once I restarted the method entry removal had not been saved and so I was unuseable again, a) with a bad breakpoint, b) with my StackOverflow It appears that Java evolution may have conspired to make this bad problem truly dreadful. (In reply to Dani Megert from comment #7) > This is a major bug and can cause lots of wasted time. If we can't fix this > then we must at least not allow to add such breakpoints in the first place. Yes. I have yet to discover a use case where a method entry breakpoint has ever helped me. Solely functionality; make Eclipse unuseable.
I didn't notice this bug, just wanted to "vote" for the importance of entry breakpoints. (In reply to Ed Willink from comment #8) > Yes. I have yet to discover a use case where a method entry breakpoint has > ever helped me. Solely functionality; make Eclipse unuseable. For example, in Spring @Bean methods, line number breakpoints are not supported ("Unable to install breakpoint in ...Config$EnhancerBySpringCGLIB$... due to missing line number attributes."). Besides, I often prefer entry breakpoints, because when editing the containing file, they are less likely to get out of place.
(In reply to Ed Willink from comment #8) > I just hit this again. I tried to set an execution breakpoint on: > I got an entry breakpoint and a > totally unuseable debugger. And again. An 'accident' setting a line breakpoint gives an entry breakpoint and a catastrophic loss in performance, provoking review and instrumentation of the latest code changes. Oops. Ah! JDT has this cretinous debug capability to go impossibly slowly. Clue: Non-debug execution is normal speed.
@Gayan, Will you be interested in working on this?
Should this bug be retitled / forked? The title is entry breakpoint doesn't work. The comments are entry breakpoint cripples performance.
I think we will go with the approach that if we cannot support this kind of breakpoint with good performance, we will not allow it to be added.
Just did a quick check and I cannot add a method entry breakpoint on inner class methods in 4.17 as mentioned in this issue.
By the way breakpoints on methods inside nested anonymous inner classes works fine in Intellij. Seems like they have a better approach for debugging than us in JDT.
In addition to my comment #9, I would like to add an argument for entry breakpoints: You can set them in classes in jars without source (using the Outline view).
@Sarika, I just checked in 2020-03 as well, i cannot add a method entry breakpoint at run method. I checked intellij and what they are doing is creating a line breakpoint when a method entry breakpoint is created. https://github.com/JetBrains/intellij-community/blob/62f6e4a07ef63d53e1ff4230b7a40ad38168d103/java/debugger/impl/src/com/intellij/debugger/ui/breakpoints/MethodBreakpoint.java#L234 Now in this inner class scenario if i put the line break point inside the run method everything works fine. So why can't we do the same ?
Version: 2021-12 (4.22) Build id: I20211124-1800 I just set some breakpoints on some default interface methods. Result - no result. Cripplingly slow. Pausing the debugger shows that execution is busy checking SHA results while loading classes. Looks like the breakpoints have put the JVM into maximum interpretation mode so that every single call is laboriously reviewed as a breakpoint candidate. Clearly this is once again totally crippling. As a minimum the user should be prompted to remove the breakpoints that are going to cripple performance. (Specifically I was setting breakpoints by toggling the left annotation bar for SerializeTestHelper in /org.eclipse.ocl.examples.xtext.tests/src/org/eclipse/ocl/examples/test/xtext/SerializeTests.java while debugging testSerialize_States.) Workaround. Rather than toggling the line to give an entry breakpoint on: default @Nullable String cs2asErrorMessages() { return null; } Adjust the text so that there is a line on which a line breakpoint can be set. e.g. default @Nullable String cs2asErrorMessages() { return null; } Rather than the user working around, why doesn;t JDT just a line breakpoint in the first place? Why doesn't the menu offer line breakpint as an option?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
