Community
Participate
Working Groups
Build Identifier: 20110218-0911 I have set a conditional breakpoint in one of my objects with the following condition: this.hashCode() == 518877755 Whenever this method is called by the application Eclipse complains that: Conditional breakpoint has compilation error(s). Reason: Evaluations must contain either an expression or a block of well-formed statements Reproducible: Sometimes Steps to Reproduce: 1. Set a conditional breakpoint in an object's method. 2. Run debugger and get that method to be executed. 3.
Created attachment 192090 [details] Screenshot of the error dialog Eclipse shows
can you provide a code snippet where you place the breakpoint that causes the problem?
The method where I set the breakpoint looks like this: public final void repaint() { assert isEventDispatchThread(); if (!isShown()) { return; } repaint(0, 0, mWidth, mHeight); } I set the conditional breakpoint on the first line of the method (i.e the assert statement).
If you need any more information don't hesitate to ask. This bug is really annoying me so am happy to help as much as I can. Have you managed to reproduce it yet?
(In reply to comment #4) > Have you managed to reproduce > it yet? I just tried it on Windows and seemed okay. public class Shelll { public int hashCode() { return 518877755; } public boolean f() { return false; } public void v() { assert f(); System.out.println("Test"); } public static void main(String[] args) { Shelll shell = new Shelll(); shell.v(); } }
I cannot reproduce either. Nicholas, is it possible to make a complete running example that causes the problem, like a class or project?
Our project is quite complicated and uses maven and the m2 plugin for Eclipse. I can try to create a simple project that shows the problem but seeing as it's intermittent I'm not sure how easy that will be. Is Eclipse responsible for parsing and setting the conditional breakpoint or is that the job of the JVM for the program being debugged? If it's the JVM reporting that the breakpoint is invalid then the bug would be there and not in Eclipse itself. I will try with another version of the JDK to see if that helps.
Using the very latest JDK 1.6.0-24 made no difference. I can still reproduce this bug. Actually for this particular breakpoint I can reproduce it every time. However, sometimes other conditional breakpoints work for me.
I can even simplify the condition to just "true" and Eclipse still reports the exact same error - that it has compilation problems.
Do your coworkers also get this problem?
(In reply to comment #8) > Using the very latest JDK 1.6.0-24 made no difference. I can still reproduce > this bug. Actually for this particular breakpoint I can reproduce it every > time. However, sometimes other conditional breakpoints work for me. We handle the evaluation of the snippet on the Eclipse side. I am wondering if this is project-settings related issue. Nicholas, can you give me a description of your project setup so I could try to re-create it? For example, what kind of project is it? what does its buildpath and classpath look like? Are there any other special tools being use than Maven and m2?
The project that has the problem is not any different in setup than the one where it works. It uses the same build tools, maven, m2 etc. It's just a java project imported from a maven project file. The classpath just contains all the projects it needs and obviously these names won't mean much so I'm not sure what pasting them here will actually achieve. What I did manage to find out is that this problem only seems to occur this particular class in the project. If I set the same breakpoint in another class in the same project it works fine. This is the only consistent thing I can find with this problem. Let me know what other information I can provide...
I can confirm this on both Helios and Indigo, running on Ubuntu 10.10 using OpenJDK6 64bit. Not even 'true' works as breakpoint condition, rendering the debugger much less useful than it used to be.
Not sure if this is related or not. Symptoms are the same. I see this in the log: !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 java.lang.NullPointerException at org.eclipse.egit.core.Activator.getPluginId(Activator.java:72) at org.eclipse.egit.core.Activator$AutoShareProjects.doAutoShare(Activator.java:201) at org.eclipse.egit.core.Activator$AutoShareProjects.access$0(Activator.java:199) at org.eclipse.egit.core.Activator$AutoShareProjects$1.visit(Activator.java:215) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at org.eclipse.egit.core.Activator$AutoShareProjects.resourceChanged(Activator.java:211) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2353) at org.eclipse.debug.core.model.Breakpoint.setAttribute(Breakpoint.java:184) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.decrementInstallCount(JavaBreakpoint.java:794) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.deregisterRequest(JavaBreakpoint.java:262) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.removeRequests(JavaBreakpoint.java:712) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.removeFromTarget(JavaBreakpoint.java:655) at org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.removeFromTarget(JavaLineBreakpoint.java:171) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.removeAllBreakpoints(JDIDebugTarget.java:1490) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.cleanup(JDIDebugTarget.java:1447) at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.shutdown(JDIDebugTarget.java:1581) at org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.stop(JDIDebugPlugin.java:297) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:565) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1161) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:595) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:691) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:598) at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:390) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:198) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Created attachment 216262 [details] Simple eclipse plugin project that reproduces the issue for me. I've seen this too and I can reproduce it, see the zipped up plugin project. It seems to depend on where the breakpoint is set. Using org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar (from my eclipse install) and a conditional break point set to 'true' I get the error. It seems to depend where the breakpoint is so perhaps its some kind of classpath visibility screw up?
same problem here using IcedTea 7.2.1 on Gentoo 64 Bit and Indigo Service Release 2 all conditional breakpoints result in a compilation error.
I have seen this behavior as well. Seems to me this bug can be moved to status CONFIRMED.
Created attachment 224760 [details] A simple Application reproducing the bug Try out the attached file as application. It should fail with conditional breakpoints at any line and with any condition. To reproduce best follow the comments in Test.java. The conditional breakpoints will work again, if you delete the method Iterator<T> tokenize(String input) I suspect that the compiler is confused by the use of this special kind of generics.
The problem occurs in eclipse up to Version 4.2 (Juno).
Have the same issue. Moreover, watch expressions throw similar errors too even on simple variables, while hovering shows values OK. I have a clean 4.2 SR1 version installed.
I reduced the test from attachment 224760 [details] a bit and ran an eclipse application in debug to see what its doing. Breakpoint at EvaluationSourceGenerator.createEvaluationSourceFromSource(String, IType, boolean, IJavaProject). It splices a method into the class's source and it generated this:- package mybug; import java.util.Iterator; public class Bug{ <T extends Number, T extends String>void ___run() throws Throwable { return true; } public Bug (){ } public static void main (String[] args) throws Exception{ } public <T extends String> T a (){ return null;} public <T extends Number> T b (){ return null;} } This is pretty clearly screwed generics wise, seemingly explaining why it doesn't work. The problem seems to occur in SourceBasedSourceGenerator. It blindly adds all declared types into a field - even though some of them are method-scoped - which it uses to generate the broken generics. If you comment out either of the generic methods from the class it works. It still generates a 'void' method that returns true but seemingly gets away with that. In this case you only have one 'T' and its all okay:- <T extends String>void ___run() throws Throwable I can't see any reason for adding generics to this method in the first place. Presumably without the generics it would just work? If they really are necessary in some obscure generics case then it will be necessary to ensure that only in-scope generic types are considered.
I too am having trouble with this, and it is making debugging really hard work ! :( Is there a fix?
Created attachment 227463 [details] Screenshot of the failing context-evaluation on the simplest statements
8 confirmations, 3 reproduction scenario's attached, screenshot. Seems it's time to move this to status CONFIRMED...
I have successfully reproduced this and is working on a patch, based on the observations from Stefan and Chris above. The main thing is to keep a stack of sets type parameters, and record the correct set when the proper type and method is visited. The fix is working in all cases except where two type parameterized methods appear on the same line (!!), since I can't find a better way of matching a method from the stack frame to a method in the source being investigated. It still requires the attention of a committer, but a good patch is better than nothing, I hope ;-)
Created attachment 227576 [details] Fix which solves the problem as shown in "Bug.java" The short version: Keep a scope/stack of typeVariable->type constraint mappings as we enter/exit types and methods, and use that to match the active set of type parameters at the breakpoint type+line. I'll be adding a proper test case for it -- tomorrow. It'd be really great if this could go into Kepler. Patch is under 250 lines. Did you author 100% of the content you’re contributing? Yes Do you have the rights to contribute this content to Eclipse? Yes Are you willing to contribute the content under the project’s license(s) (e.g. EPL) Yes
thanks for your work, Jesper It will hopefully find it's way into Kepler...
Thanks for taking the time to create a patch for this Jesper, I will review it as soon as I can.
Created attachment 227639 [details] Test case Test case for conditional breakpoint set in generic classes with clashing type parameter names. It's a fairly high-level test, loads a file, sets some breakpoints, checks that they are correctly skipped, since they use "false" for expression (except the last one). Tricky since the tests suppress the "syntax error"-dialogs and just breaks. I couldn't find more low-level test for this area (i.e. just testing the visitor) Ran the test suite, didn't see any regressions.
*** Bug 197892 has been marked as a duplicate of this bug. ***
*** Bug 283712 has been marked as a duplicate of this bug. ***
*** Bug 332002 has been marked as a duplicate of this bug. ***
*** Bug 344856 has been marked as a duplicate of this bug. ***
Damng, four dupes -- so it wasn't just *my* itch...
So far the patch is good, I would like to add some more tests for other locations affected by it, like: 1. The display view 2. editor / var view inspect 3. editor / var view display 4. editor / var view execute
(In reply to comment #35) > So far the patch is good, I would like to add some more tests for other > locations affected by it, like: > Forgot to mention the 'watch' action and the expressions view. Also should add an example to the testing wiki as well: http://wiki.eclipse.org/Debug/Test_Script
Pushed patch to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=1aedb345895fdc00d22405a63e97e9aff1443747 Thank you very much Jesper for taking the time to look into this.
Pushed a pile more tests and a bug fix to correctly compute the type erasure when we try to eval something like: new StepIntoSelectionWithGenerics<String>().new InnerClazz<Integer>().new InnerClazz2<Double>().hello() http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=938935fa3fd958634817837fc9e725681f783c3f
Pushed the remainder of the tests to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3d65d3bd3bddf3661c91c69ba3ea189f08a939b7
I thought 'noteworthy' was a reminder to add it to the release note?
(In reply to comment #40) > I thought 'noteworthy' was a reminder to add it to the release note? It is, and it has also been added to the New and Noteworthy for M6: http://git.eclipse.org/c/platform/eclipse.platform.news.git/commit/?id=2652054023d11f319ca68dd3aa37e687b6248d86
*** Bug 278146 has been marked as a duplicate of this bug. ***
This bug is not fully fixed in the latest Kepler nor 4.2.2. In the "A simple Application reproducing the bug" attachment, by adding "tokenize(name);" to the main and putting the a breakpoint in the constructor of ItemIterator, putting the mouse over "this.input" works but over "input" (the local variable) doesn't. It seems to be related to generics again.
(In reply to Pierre-Luc Bertrand from comment #43) > This bug is not fully fixed in the latest Kepler nor 4.2.2. In the "A simple > Application reproducing the bug" attachment, by adding "tokenize(name);" to > the main and putting the a breakpoint in the constructor of ItemIterator, > putting the mouse over "this.input" works but over "input" (the local > variable) doesn't. It seems to be related to generics again. I was able to reproduce using 'tokenize(name);' inside Bug's constructor. Thanks for reporting! Michael, how do you do it in JDT Debug in a case like this, re-open or create a new bug?
(In reply to Jesper Moller from comment #44) > (In reply to Pierre-Luc Bertrand from comment #43) > > This bug is not fully fixed in the latest Kepler nor 4.2.2. In the "A simple > > Application reproducing the bug" attachment, by adding "tokenize(name);" to > > the main and putting the a breakpoint in the constructor of ItemIterator, > > putting the mouse over "this.input" works but over "input" (the local > > variable) doesn't. It seems to be related to generics again. > > I was able to reproduce using 'tokenize(name);' inside Bug's constructor. I'm not sure what happened, I'm fairly certain I saw the problem here in my Java8 workspace, but now I can't reproduce anymore. Perhaps confirmation bias clouded my judgment ;-) Can I get someone else to reproduce also, on Kepler SR1? By the way, the fix never went info 4.2.2, so don't try that. (That being said, hover over the local 'input' doesn't work for me neither, but I'm not sure it's the same issue)
(In reply to Pierre-Luc Bertrand from comment #43) > This bug is not fully fixed in the latest Kepler nor 4.2.2. In the "A simple > Application reproducing the bug" attachment, by adding "tokenize(name);" to > the main and putting the a breakpoint in the constructor of ItemIterator, > putting the mouse over "this.input" works but over "input" (the local > variable) doesn't. It seems to be related to generics again. Apologies for the many confusing messages. Here's what I've found: 1) Re-reading comment #43, I now realize that it didn't claim that conditional breakpoints were still failing to compute in the presence of generics, only that hovering over the parameter 'input' doesn't work. (I thought I confirmed the conditional breakpoint, but it turned out I had written 'this' instead of 'true', which is obviously not a boolean - so the joke's on me. The bug really is fixed.) 2) The hover over 'input' is not related to the generics issue, nor a name resolution issue, but rather something to do with the synthetic constructor parameter for the inner class Bug.ItemIterator. Turning ItemIterator into a static nested class fixes the issue. This is thus an unrelated issue to this one, and should be reported as a separate bug -- a quick search didn't find it reported elsewhere. Again, sorry for the extra noise.
(In reply to Jesper Moller from comment #44) > Michael, how do you do it in JDT Debug in a case like this, re-open or > create a new bug? I prefer we just reopen the existing bug, unless a whole new issues is caused, then a new bug would suffice > Again, sorry for the extra noise. No worries. Its better to check it out than to ignore it.
Who should be reopening this bug ? I don't think I have the rights to perform this action.
(In reply to Pierre-Luc Bertrand from comment #48) > Who should be reopening this bug ? I don't think I have the rights to > perform this action. This bug shouldn't be re-opened, as the conditional breakpoint issue is resolved as reported. Your problem about inspecting locals (by hovering) is pretty old, quite tricky, and at the moment, I can't seem to find it... But I'll look some more.
I took the suggestion from comment 47 to just reopen it but I can open a new one. Is there one already existing ?
(In reply to Pierre-Luc Bertrand from comment #50) > I took the suggestion from comment 47 to just reopen it but I can open a new > one. Is there one already existing ? I see - however comment 47 was in response to an earlier reply which I retracted (but there's no way to delete a comment). I think I've found your bug: Have a look at bug 426251. If appears to be specific to locals in constructors of inner classes, I guess that applies in this case, too.
Thanks for finding this other bug. My bug is not limited to constructor though, it's when there is a generic that extends another class. The screenshot of his bug is also showing that his class is not a generic one.
*** Bug 338357 has been marked as a duplicate of this bug. ***
