Community
Participate
Working Groups
I'm seeing this issue intermittently with Indigo M5. Sometimes when I ctrl-space following adding a '.' no proposals are found. i.e.: editorPart.getActivePage(). I just discovered that proposals *are* found if I leave off the '.': editorPart.getActivePage() But of course that gets me: editor.getActivePage()addPropertyChangeListener(listener); I'm not seing errors in log or system console and wasn't able to find a similar report.
Do you use Mylyn ?
Not actively but the feature is installed and I just checked and it is active. Should I try deactivating the plugin the next time this happens? I wish the issue weren't so non-repeatable.
Yes, it would help to ascertain if Mylyn is causing the problem. (In the past there have been number of bugs where Mylyn interferes with content assist).
OK, I'll check on it the next time this happens. Thanks.
>I just discovered that proposals *are* found if I leave off the '.': I guess it will then find proposals starting with "editorPart", right? I'm sorry, I can't reproduce this and we've never heard of that. Is there anything in the .log?
(In reply to comment #5) > >I just discovered that proposals *are* found if I leave off the '.': > I guess it will then find proposals starting with "editorPart", right? Exactly, just as if the '.' were there. > > I'm sorry, I can't reproduce this and we've never heard of that. Is there > anything in the .log? No, see above. I'm going to keep an eye out for it happening again and see if I can at least isolate Mylyn from it,
(In reply to comment #6) > (In reply to comment #5) > > >I just discovered that proposals *are* found if I leave off the '.': > > I guess it will then find proposals starting with "editorPart", right? > > Exactly, just as if the '.' were there. OK, so it is not finding proposals prefixed with "editorPart" but proposals for that type. Sorry, there's nothing we can do without more details/steps.
Sorry, WORKSFORME is not really an appropriate response. I am having this difficulty even if it is intermittent. See comments above, Mylyn ma be implicated and I'm going to try to get a more repeatable case.
(In reply to comment #8) > Sorry, WORKSFORME is not really an appropriate response. It's a perfect response: it says that it works for me (and others). It doesn't says "DOES WORK FOR YOU". You can reopen if you have more data but at this point there is nothing we can or will do with this report.
Dani, First, I'm not sure we're understanding each other: ">> Exactly, just as if the '.' were there. >OK, so it is not finding proposals prefixed with "editorPart" but proposals for that type. It is not finding *any* proposals. Now as to process, I don't know if there is some reason that you're anxious to close this bug, but with respect, I've never seen a legitimate bug dismissed out of hand like this. For example, please see this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=331485 Which certainly could not be reproduced but has been open for over a year. "Works for me" is not meant to be take literally. Do you just not believe me, or don't care? For example, what OS's have you tested this against? Have you run it with the same or similar configuration to mine? Have you even asked what my configuration is? There are practical reasons not to resolve something even if you are in doubt about whether it is a real issue. We're on M5 and it would be really nice to have this fixed for Indigo release. But if people aren't going to see it it's an issue that won't be resolvable. Here are some general guidelines that might be helpful: http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use " WORKSFORME (generally, INVALID means the report is just bogus, **WORKSFORME means the report is not a problem**" A nice right up for Mozilla: https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla You should not resolve a bug as WFM if: "the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows). the bug has been **reproduced by some people** but can't be reproduced by other people."
(In reply to comment #10) > https://bugs.eclipse.org/bugs/show_bug.cgi?id=331485 > > Which certainly could not be reproduced but has been open for over a year. Um..three months actually, but hopefully you see my point. ;0
>First, I'm not sure we're understanding each other: > >">> Exactly, just as if the '.' were there. >>OK, so it is not finding proposals prefixed with "editorPart" but proposals >for >that type. >It is not finding *any* proposals. Miles, what I understood is that you sometimes don't get proposals when hitting Ctrl+Space after a '.'. But when leaving the '.' away it seems to work. I do believe that you see the bug but we try to have bugs in the ASSIGNED box that are in a state where we can actually do something with it and those which are not yet investigated in the NEW state. WORKSFORME is not the same as INVALID (which would indeed signal that your bug is not good), if you click on the 'Status' link above to get the official Eclipse definition it says: All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened. This describes exactly the state of this bug. That having said, you can easily reopen if more information appears. So, please accept the way we work. For your concrete problem it doesn't matter at all in which state the bug is because as soon as more information is provide we will take another look at it.
Here is more information if it is of any interest at all. In this case, I don't get any completion suggestions at all. The other data point is that I'd just installed WTP. Message: While loading class "org.eclipse.jdt.internal.debug.ui.MemberActionFilter", thread "Thread[Worker-6,5,main]" timed out waiting (5001ms) for thread "Thread[main,6,main]" to finish starting bundle "org.eclipse.jdt.debug.ui_3.6.0.v20110207 [112]". To avoid deadlock, thread "Thread[Worker-6,5,main]" is proceeding but "org.eclipse.jdt.internal.debug.ui.MemberActionFilter" may not be fully initialized. Trace: org.osgi.framework.BundleException: State change in progress for bundle "reference:file:plugins/org.eclipse.jdt.debug.ui_3.6.0.v20110207.jar" by thread "main". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1087) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:297) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:460) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.jdt.internal.debug.ui.ActionFilterAdapterFactory.getAdapter(ActionFilterAdapterFactory.java:42) at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:295) at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66) at org.eclipse.ui.internal.util.Util.getAdapter(Util.java:109) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.getActionFilter(ActionExpression.java:471) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.preciselyMatches(ActionExpression.java:524) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.isEnabledFor(ActionExpression.java:499) at org.eclipse.ui.internal.ActionExpression$SingleExpression.isEnabledFor(ActionExpression.java:743) at org.eclipse.ui.internal.ActionExpression.isEnabledFor(ActionExpression.java:1053) at org.eclipse.ui.internal.decorators.DecoratorDefinition.isEnabledFor(DecoratorDefinition.java:282) at org.eclipse.ui.internal.decorators.DecoratorManager.getDecoratorsFor(DecoratorManager.java:382) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecoratorsFor(LightweightDecoratorManager.java:315) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:340) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:370) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:330) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 29 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1087) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:297) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:460) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.jdt.internal.debug.ui.ActionFilterAdapterFactory.getAdapter(ActionFilterAdapterFactory.java:42) at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:295) at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66) at org.eclipse.ui.internal.util.Util.getAdapter(Util.java:109) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.getActionFilter(ActionExpression.java:471) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.preciselyMatches(ActionExpression.java:524) at org.eclipse.ui.internal.ActionExpression$ObjectStateExpression.isEnabledFor(ActionExpression.java:499) at org.eclipse.ui.internal.ActionExpression$SingleExpression.isEnabledFor(ActionExpression.java:743) at org.eclipse.ui.internal.ActionExpression.isEnabledFor(ActionExpression.java:1053) at org.eclipse.ui.internal.decorators.DecoratorDefinition.isEnabledFor(DecoratorDefinition.java:282) at org.eclipse.ui.internal.decorators.DecoratorManager.getDecoratorsFor(DecoratorManager.java:382) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecoratorsFor(LightweightDecoratorManager.java:315) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:340) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:370) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:330) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #13) That's an ugly exception. It means that the plug-in (in this case JDT Debug) didn't get loaded properly. If this happens regularly then I suggest to file a bug report against JDT Debug.
OK, it's happening again. :( And yes, after I installed Mylyn. But still, I can't see anything here that implicates Mylyn. It looks like JDT is sending a null to control so this is probably a symptom of something deeper, but there isn't any way for me to diagnose that. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:4282) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3935) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3612) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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) Caused by: java.lang.NullPointerException at org.eclipse.swt.widgets.Control.internal_new_GC(Control.java:2103) at org.eclipse.swt.graphics.GC.<init>(GC.java:171) at org.eclipse.swt.graphics.GC.<init>(GC.java:134) at org.eclipse.swt.widgets.Table.computeSize(Table.java:458) at org.eclipse.swt.layout.GridData.computeSize(GridData.java:491) at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:218) at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:194) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1194) at org.eclipse.swt.widgets.Composite.resized(Composite.java:933) at org.eclipse.swt.widgets.Control.setFrameSize(Control.java:3784) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5460) at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method) at org.eclipse.swt.internal.cocoa.NSWindow.setFrame(NSWindow.java:292) at org.eclipse.swt.widgets.Shell.setBounds(Shell.java:1623) at org.eclipse.swt.widgets.Control.setSize(Control.java:4066) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.createProposalSelector(CompletionProposalPopup.java:614) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$22(CompletionProposalPopup.java:571) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:498) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482) at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:377) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) ... 22 more
>OK, it's happening again. :( So far this bug never mentioned an NPE. So why do you think "it" happened again? Can you reproduce it? If so, the easiest to find out more would be to remote debug your workspace.
(In reply to comment #16) > >OK, it's happening again. :( > So far this bug never mentioned an NPE. So why do you think "it" happened > again? I'm speaking from a user's perspective here. As you may have experienced as well, sometimes SWT bugs seem to be swallowed or obscured by other things. But no, I don't know for certain that these two occurrences are from same cause. > > Can you reproduce it? If so, the easiest to find out more would be to remote > debug your workspace. The trouble is that it is intermittent and I can't determine a proximate cause for it to *begin* happening, though I can stop it from happening by closing and reopening the affected editor or by de-activating and activating the Mylyn task. Please see referenced bug. I think I can get it happening under self-hosting as well so if there is something in particular that you'd like me to check out, please let me know.
I do think the NPE is unrelated and that the empty proposal comes from Mylyn which actively filters proposals depending on active/selected tasks. You could start a second workspace and then connect it to your work/normal workspace. Set a breakpoint for NPE and one in org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(boolean) when the count is 0.
Could this possibly be a duplicate of bug 323739?
(In reply to comment #19) > Could this possibly be a duplicate of bug 323739? It might be but unlike there I didn't see anything in the console log. I'll dig deeper the next time (if) it happens again.
