Bug 382646 - AssertionFailedException for JavaSourceViewer.prepareDelayedProjection
Summary: AssertionFailedException for JavaSourceViewer.prepareDelayedProjection
Status: RESOLVED DUPLICATE of bug 400374
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.8   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2012-06-14 12:36 EDT by Ed Willink CLA
Modified: 2016-02-03 16:57 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2012-06-14 12:36:39 EDT
RC4: I'm trying to navigate from search results to code and getting

org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.prepareDelayedProjection(JavaSourceViewer.java:658)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.internalDoSetInput(JavaEditor.java:2582)
	at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2571)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1395)
	at org.eclipse.ui.texteditor.AbstractTextEditor.setInputWithNotify(AbstractTextEditor.java:4286)
	at org.eclipse.ui.texteditor.AbstractTextEditor.setInput(AbstractTextEditor.java:4308)
	at org.eclipse.jdt.internal.ui.search.JavaSearchEditorOpener.showInEditor(JavaSearchEditorOpener.java:96)
	at org.eclipse.jdt.internal.ui.search.JavaSearchEditorOpener.showWithReuse(JavaSearchEditorOpener.java:75)
	at org.eclipse.jdt.internal.ui.search.JavaSearchEditorOpener.openElement(JavaSearchEditorOpener.java:40)
	at org.eclipse.jdt.internal.ui.search.JavaSearchEditorOpener.openMatch(JavaSearchEditorOpener.java:52)
	at org.eclipse.jdt.internal.ui.search.JavaSearchResultPage.showMatch(JavaSearchResultPage.java:198)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage$7.run(AbstractTextSearchViewPage.java:938)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage.showMatch(AbstractTextSearchViewPage.java:941)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage.showCurrentMatch(AbstractTextSearchViewPage.java:1006)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage.gotoNextMatch(AbstractTextSearchViewPage.java:971)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage.handleOpen(AbstractTextSearchViewPage.java:1430)
	at org.eclipse.jdt.internal.ui.search.JavaSearchResultPage.handleOpen(JavaSearchResultPage.java:577)
	at org.eclipse.search.ui.text.AbstractTextSearchViewPage$5.open(AbstractTextSearchViewPage.java:756)
	at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:866)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:864)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1152)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1256)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:275)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:269)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:309)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	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:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	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:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Comment 1 Ed Willink CLA 2012-06-14 12:40:03 EDT
The proklem entries are JUnit classes and methods. Non-JUnit results seem fine.
Comment 2 Dani Megert CLA 2012-06-14 15:19:30 EDT
Ed, a test case would be great.
Comment 3 Ed Willink CLA 2012-06-14 15:37:37 EDT
It seems intermittent. The bad search is still in my search history.

One of the JUnit test classes now works.

The other continues to give a silent exception on a go-to-method, but an assertion failed poop-up on a go-to-class.


FWIW the search was for references to the UML2Ecore2Pivot class in the MDT/OCL GIT projects (plugins, examples, tests).
Comment 4 Dani Megert CLA 2012-06-15 03:31:58 EDT
(In reply to comment #3)
> It seems intermittent. The bad search is still in my search history.
> 
> One of the JUnit test classes now works.
> 
> The other continues to give a silent exception on a go-to-method, but an
> assertion failed poop-up on a go-to-class.

Just to clarify: when you say "JUnit test class", this is a normal search result from a normal class and not some special search match created by e.g. a JUnit search participant (which would not come from the SDK)?

I assume you cannot share the workspace, but could you debug it for me on your machine and paste the stack traces that set org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.fIsSetVisibleDocumentDelayed?

Thanks.
Comment 5 Ed Willink CLA 2012-06-15 06:07:11 EDT
By test class, I meant that the only distinguishing feature of the failing entries in the JDT search was that they inherit TestCase. Given the intermittency, probably a red herring.

To debug it would require me to make it happen in a nested workspace, so it's hard to help.
Comment 6 Dani Megert CLA 2012-06-15 07:01:29 EDT
(In reply to comment #5)
> By test class, I meant that the only distinguishing feature of the failing
> entries in the JDT search was that they inherit TestCase. Given the
> intermittency, probably a red herring.
> 
> To debug it would require me to make it happen in a nested workspace, so it's
> hard to help.

You can start a debug server with your IDE. This is very handy, as it allows you to connect the Debugger (from another Eclipse instance) to your IDE at any point. I always start like that.

-vmargs -Xrunjdwp:server=y,transport=dt_socket,address=14143,suspend=n
(use another socket if it is already in use)

For debugging see:
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Fconcepts%2Fcremdbug.htm
Comment 7 Ed Willink CLA 2012-06-15 07:23:18 EDT
Interesting. I think I'll always start that way too.
Comment 8 Ed Willink CLA 2012-06-15 09:56:41 EDT
It seems the offending class(es) have become downgraded somehow.

Completion assist does not suggest imports.
Go to declaration doesn't work.
Comment 9 Dani Megert CLA 2012-06-16 03:22:11 EDT
(In reply to comment #8)
> It seems the offending class(es) have become downgraded somehow.
> 
> Completion assist does not suggest imports.
> Go to declaration doesn't work.

Just some ideas for the underlying issue:
- Maybe you use Mylyn and Mylyn tries to hide those classes.
- Your build path is not complete i.e. you got those classes indirectly via 
  PDE, but they are neither in one of your bundles nor directly required by 
  one of your bundles.
Comment 10 Ed Willink CLA 2012-06-16 04:56:11 EDT
(In reply to comment #9)
> - Maybe you use Mylyn and Mylyn tries to hide those classes.

I try hard to not use Mylyn since my experience is that Mylyn variously conspires to hide things and to participate in obscure platform bugs.

I only explicitly install Wikitext, but too often parasitic integrations bring in too much.

> - Your build path is not complete i.e. you got those classes indirectly via 
>   PDE, but they are neither in one of your bundles nor directly required by 
>   one of your bundles.

I tried a rebuild in case the build path was stale. I don't reference the bundles directly, just transitively. It seems to me that if import ...X is not a compilation error, X should be available as a Completion Assist and navigable via Open Definition.

--

I raised this one because I could pin it down to a stack trace.

Overall I find Juno very unsatisfactory; and it is far from clear whether e4, JDT, EGIT, Xtext Index, Mylyn or something else is causing the trouble.

I lost all JDT Completion proposals in my workspace at about M2 even though they worked in a new workspace. While adding templates to one of my own editors I found some documentation referring to the the JDT preferences page and was able to restore them. Weird that three workspaces on two machines lost the preferences at the same time.

I cannot actually understand the entries JDT Advanced Cntent Assist preferences page. No hover text and what is the difference between Java, Java Type, Java Non-Type, Template propsals. So I reset to defaults and my preferences are all gone again since it seems Type Proposals are non-default.

[The Completion Proposals dialog really should have a Preferences... link to guide the user dissatisfied with the miserable offerings.]
Comment 11 Dani Megert CLA 2012-06-18 07:14:22 EDT
(In reply to comment #10)

> I lost all JDT Completion proposals in my workspace at about M2 even though
> they worked in a new workspace. While adding templates to one of my own editors
> I found some documentation referring to the the JDT preferences page and was
> able to restore them. Weird that three workspaces on two machines lost the
> preferences at the same time.

This is caused by Mylyn which overrides the existing content assistant processors. When you then switch to another install where Mylyn is not installed or you disable/uninstall Mylyn, content assist is doomed. In the latest version, a dialog should come up with a link to reset the settings back to the default.


> I don't reference the
> bundles directly, just transitively. It seems to me that if import ...X is 
> not a compilation error, X should be available as a Completion Assist and 
> navigable via Open Definition.
I agree, it should, but it doesn't always do (see bug 73957 for details).


Are you able to reproduce and debug the problem? I suspect the root cause is bug 73957.
Comment 12 Ed Willink CLA 2012-06-18 07:29:53 EDT
(In reply to comment #11)
> ... Mylyn, content assist is doomed. 

Ah. Prejudice confirmed. Where is the Mylyn installation is forbidden P2 option?

> > I don't reference the
> > bundles directly, just transitively. It seems to me that if import ...X is 
> > not a compilation error, X should be available as a Completion Assist and 
> > navigable via Open Definition.
> I agree, it should, but it doesn't always do (see bug 73957 for details).
> 
> 
> Are you able to reproduce and debug the problem? I suspect the root cause is
> bug 73957.

Yes/No.

Bug 73957 is about transitive access that is not transitively exported. I have a file that compiles and runs fine but for which there is no content assist on any type (e.g not to IOException, String, or to a function in the same file.)

The file still has no navigation three days later. So what would you like me to look at?
Comment 13 Dani Megert CLA 2012-06-18 07:44:23 EDT
(In reply to comment #12)
> > Are you able to reproduce and debug the problem? I suspect the root cause is
> > bug 73957.
> 
> Yes/No.
> 
> Bug 73957 is about transitive access that is not transitively exported.
Bug 73957 also causes type hierarchies and content assist to not work in certain scenarios.

> The file still has no navigation three days later. So what would you like me 
> to look at?
If you have the assertion failure from comment 0, I'd like you to debug it as outlined in comment 4.
Comment 14 Dani Megert CLA 2012-06-26 04:20:17 EDT
Ed, any update?
Comment 15 Ed Willink CLA 2012-06-27 06:19:55 EDT
(In reply to comment #14)
> Ed, any update?

I'm afraid the problem has gone away. I can now navigate from the test class that previously caused trouble.

A possible cause might be e4's lack of perspective coherence. In e3 switching between Java and Debug perspectives did not change the open editor. In e4 it changes; really irritating.

Within a debugger context, there is additional hover text, so perhaps debugger and Mylyn conspired to lose navigation.

However I tried re-opening the problem file directly and via a breakpoint encounter, but cannot reproduce the problem.
Comment 16 Dani Megert CLA 2012-06-27 07:41:33 EDT
Please reopen when you see this again and you're able to debug the issue to provide more details. Thanks.
Comment 17 Markus Keller CLA 2016-02-03 16:57:53 EST

*** This bug has been marked as a duplicate of bug 400374 ***