Bugzilla – Full Text Bug Listing
| Summary: | Breakpoints sometimes invisible | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Kris De Volder <kdevolder> | ||||||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | loskutov, sarika.sinha | ||||||||
| Version: | 4.7 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
In the screenshot, notice that the icon for the KeyBindingDispatcher editor tab has a different icon than the usual `.java` editor. I think that's probably an important clue as to why the breakpoints are 'invisible'. I could not reproduce with a simple application. If you can attach a project where you can see that happening it will help. (In reply to Sarika Sinha from comment #2) > I could not reproduce with a simple application. If you can attach a project > where you can see that happening it will help. I think I observe this every time I switch the platform to a new daily build and have breakpoints still referring to classes from old platform jars. The breakpoints itself are installed (because all the types are still there) but the jar paths are changed and so we can't match the current class editor to the old jar path => no annotation in ruler. (In reply to Andrey Loskutov from comment #3) > (In reply to Sarika Sinha from comment #2) > > I could not reproduce with a simple application. If you can attach a project > > where you can see that happening it will help. > > I think I observe this every time I switch the platform to a new daily build > and have breakpoints still referring to classes from old platform jars. The > breakpoints itself are installed (because all the types are still there) but > the jar paths are changed and so we can't match the current class editor to > the old jar path => no annotation in ruler. Yes changing the jar can lead to inconsistencies but this bug I thought talks about new breakpoints created after stepping into. Created attachment 270717 [details]
another screenshot
Just happened: I've opened my workspace I've used yesterday with SDK-I20170921-2000 build but today I've switched to SDK-I20170927-2000 and immediately failed with the breakpoint at SelectionService, loaded NOT from source but from jar.
Trying to open breakpoints view and clicking on the breakpoint produces the error the jar is missing (sure!) but breakpoint itself is available in the breakpoints view.
null
org.eclipse.jdt.debug.ui
Error
Thu Sep 28 10:01:56 CEST 2017
Internal Error
Java Model Exception: Java Model Status [/data2/eclipse4.8/eclipse/plugins/org.eclipse.ui.workbench_3.111.0.v20170921-0624.jar is not on its project's build path]
at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:570)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:247)
at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:505)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:241)
at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:505)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:241)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:583)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:320)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:306)
at org.eclipse.jdt.internal.core.Openable.getBuffer(Openable.java:285)
at org.eclipse.jdt.internal.core.AbstractClassFile.getBuffer(AbstractClassFile.java:212)
at org.eclipse.jdt.internal.core.AbstractClassFile.getSource(AbstractClassFile.java:324)
at org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setBreakpoint(JavaBreakpointConditionEditor.java:280)
at org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setInput(JavaBreakpointConditionEditor.java:218)
at org.eclipse.jdt.internal.debug.ui.breakpoints.CompositeBreakpointEditor.setInput(CompositeBreakpointEditor.java:137)
at org.eclipse.jdt.internal.debug.ui.breakpoints.AbstractDetailPane.display(AbstractDetailPane.java:298)
at org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy.setupPane(DetailPaneProxy.java:225)
at org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy.display(DetailPaneProxy.java:124)
at org.eclipse.debug.internal.ui.views.variables.VariablesView.refreshDetailPaneContents(VariablesView.java:1202)
at org.eclipse.debug.internal.ui.views.variables.VariablesView$8.selectionChanged(VariablesView.java:1141)
at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:872)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil.lambda$0(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173)
at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:869)
at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1238)
at org.eclipse.jface.viewers.StructuredViewer.lambda$0(StructuredViewer.java:1261)
at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:261)
at org.eclipse.jface.util.OpenStrategy.access$5(OpenStrategy.java:256)
at org.eclipse.jface.util.OpenStrategy$1.lambda$1(OpenStrategy.java:426)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4811)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4420)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
(In reply to Kris De Volder from comment #0) > - The editor was not opened by clicking any file in the workspace but was > opened as a result of clicking in the stack of the debugger view after > hitting a BP in much deeper stackframe. The source-code displayed is from a > source-bundle installed in the target platform. Please note that the editor icon differs from the Java class file icon used for sources where the class files were properly on the classpath - the icon shown on KeyBindingDispatcher is for Java code NOT on the classpath of the current launch. To confirm. 1. Yes, these are newly created breakpoints. 2. As Andrey also noted, and I also pointed out, the editor tab shows a different than usual icon which is probably a clue that it has something todo with the source in the editor not being on the classpath. I'll try later to create a sample project. I think I might be able to following, up on the 'not on classpath' theory and setting up something similar to the stuff I made the screenshot with. Okay, I was able to reproduce it again with simple sample project. I'll attach it shortly. Here are the steps to reproduce it. 1. Download Eclipse installer from here: https://www.eclipse.org/downloads/download.php?file=/oomph/epp/oxygen/R/eclipse-inst-linux64.tar.gz (Or equivalent for your platform if its not linux) 2. fire it up and install Eclipse for RCP / RAP developers. 3. import the project from the attached 'invisible-breakpoints.zip' file. 4. Place breakpoint in the SampleHanlder.execute method 5. Right Click the project and do "Debug As Eclipse Application" 6. Once in the runtime workbench, close welcome window. Then Press CTRL-6, you should trigger the SampleHandler and hit the breakpoint. 7. In the debug view, walk up the stack upto KeybindingDispatcher.processKeyEvent (i.e. similar to how its shown in my screenshot) 8. Place breakpoints in that method. => The breakpoints appear in the Breakpoints view, but not in the editor. You can try stepping / running and the breakpoints do work, they just aren't visible in the editor that created them. Created attachment 270733 [details]
sample project
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |
Created attachment 270709 [details] screenshot Sometimes, when you step into code and then place breakpoints there, the breakpoints are 'invisible' in the editor left margin. What I means is: 1. The breakpoints are effectively created and functional (they are shown in the breakpoints view, and they also make execution stop when that point is reached). 2. But there is no indication of any breakpoints shown in the editor margin on the left, where breakpoint markers would normally be shown. I don't know exactly a logic to reproduce it, but after running into frustrating bug a bunch of times finally decided to make a bug-report even though I don't have an exact 'how to reproduce' recipe. I think this probably has something to do with whether or not the source file in which we are placing breakpoint is on the classpath of the/a project. But I'm not entirely sure of that. See attached screenshot which shows that: - there are several breakpoints shown in the breakpoint view. - there are *no* breakpoints shown in the editor which is opened on the corresponding source. Other potentially relevant info that may help reproduce: - The breakpoints that are shown in breakpoint view were created by clicking in the editor margin in the way you usually create breakpoints (but this only made the breakpoints appear in the BP view, not the editor used to create them) - The editor was not opened by clicking any file in the workspace but was opened as a result of clicking in the stack of the debugger view after hitting a BP in much deeper stackframe. The source-code displayed is from a source-bundle installed in the target platform.