Community
Participate
Working Groups
The following problem was reported via the automated error reporting: Message: Unhandled event loop exception java.lang.NullPointerException: null at java.util.Arrays.sort(null:-1) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.sortProposals(CompletionProposalPopup.java:2007) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:568) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:560) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$13.run(CompletionProposalPopup.java:1637) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.incrementalComplete(CompletionProposalPopup.java:1630) at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1746) at org.eclipse.recommenders.internal.snipmatch.rcp.completion.SnipmatchCompletionEngine$6.modifyText(SnipmatchCompletionEngine.java:252) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:180) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) Bundles: | org.eclipse.jface.text | 3.11.0.v20160314-1855 | 3.11.0.v20160505-1301 | | org.eclipse.recommenders.snipmatch.rcp | 2.3.0.v20160129-1024 | 2.4.0.v20160607-1609 | | org.eclipse.swt | 3.105.0.v20160317-0027 | 3.105.0.v20160603-0902 | Operating Systems: | Windows | 6.1.0 | 10.0.0 | The above information is a snapshot of the collected data. Visit https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/570ffee7e4b013ab26a8eed8 for the latest data. Thank you for your assistance. Your friendly error-reports-inbox. Created on behalf of andreas.sewe@xxxxxx.xxx
(In reply to EPP Error Reports from comment #0) > The following problem was reported via the automated error reporting: > > Message: Unhandled event loop exception > java.lang.NullPointerException: null > at java.util.Arrays.sort(null:-1) Luckily, there exist incidents [1] with line numbers for Arrays.sort: at java.util.Arrays.sort(Arrays.java:1438) in JRE 1.8.0_31-b13 and 1.8.0_92-b14. Line 1438 reads TimSort.sort(a, 0, a.length, c, null, 0, 0); so apparently the array to be sorted is null. [1] <https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/incidents/57865dd9e4b0b5f63da6c156>
The root cause is that ContentAssistant#computeCompletionProposals returns null. There is two reasons why this can happen (see Bug 499654): An exception occurs within the ExceptionLoggingSafeRunnable or ContentAssistant#getProcessor does not return an instance of ISubjectControlContentAssistProcessor. The former should have been logged at ERROR level as well. Here's two searches for incidents on the same day [1,2], which could be the error logged by the ExceptionLoggingSafeRunnable. [1] <https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/incidents/?c:!((t:reporter-email,val:%27developer@*%27),(t:created-on,op:after,val:%272016-04-14%27),(t:created-on,op:before,val:%272016-04-15%27)),sort:!((prop:timestamp,dir:DESCENDING))> [2] <https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/incidents/?c:!((t:reporter-email,val:%27ghaith.hachem@*%27),(t:created-on,op:after,val:%272016-07-18%27),(t:created-on,op:before,val:%272016-07-19%27)),sort:!((prop:timestamp,dir:DESCENDING))>
(In reply to Andreas Sewe from comment #2) > The root cause is that ContentAssistant#computeCompletionProposals returns > null. There is two reasons why this can happen (see Bug 499654): An > exception occurs within the ExceptionLoggingSafeRunnable or > ContentAssistant#getProcessor does not return an instance of > ISubjectControlContentAssistProcessor. > > The former should have been logged at ERROR level as well. Here's two > searches for incidents on the same day [1,2], which could be the error > logged by the ExceptionLoggingSafeRunnable. > > [1] > <https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/incidents/?c:! > ((t:reporter-email,val:%27developer@*%27),(t:created-on,op:after,val:%272016- > 04-14%27),(t:created-on,op:before,val:%272016-04-15%27)),sort:!((prop: > timestamp,dir:DESCENDING))> There are no other errors logged close to the incident this bug is about. > [2] > <https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/incidents/?c:! > ((t:reporter-email,val:%27ghaith.hachem@*%27),(t:created-on,op:after,val: > %272016-07-18%27),(t:created-on,op:before,val:%272016-07-19%27)),sort:! > ((prop:timestamp,dir:DESCENDING))> The error reports *sent* at the same time don't seem to have any relation to the problem at hand; in particlar, they happen in the background (org.eclipse.core.internal.jobs.Worker.run and don't seem to be logged by the ExceptionLoggingSafeRunnable. The likely interpretation thus seems to be that ContentAssistant#getProcessor did not return an instance of ISubjectControlContentAssistProcessor.
(In reply to Andreas Sewe from comment #3) > The likely interpretation thus seems to be that > ContentAssistant#getProcessor did not return an instance of > ISubjectControlContentAssistProcessor. Looking at ContentAssistant#getProcessor, it seems likely that this method just returned null (which it can do on a BadLocationException) or if ContentAssistant#fProcessors (a Map) is null or doesn't contain an entry for the current content type (we register a processor for DEFAULT_CONTENT_TYPE).
(In reply to Andreas Sewe from comment #4) > (In reply to Andreas Sewe from comment #3) > > The likely interpretation thus seems to be that > > ContentAssistant#getProcessor did not return an instance of > > ISubjectControlContentAssistProcessor. > > Looking at ContentAssistant#getProcessor, it seems likely that this method > just returned null (which it can do on a BadLocationException) or if > ContentAssistant#fProcessors (a Map) is null or doesn't contain an entry for > the current content type (we register a processor for DEFAULT_CONTENT_TYPE). Alternative explanation: Our own o.e.r.internal.snipmatch.rcp.completion.JavaContentAssistProcessor and o.e.r.internal.snipmatch.rcp.completion.TextContentAssistProcessor are indeed *not* instances of ISubjectControlContentAssistProcessor, which causes a null list of proposals to be returned from ContentAssistant#computeCompletionProposals(IContentAssistSubjectControl, int). Now, that overload of ContentAssistant#computeCompletionProposals is called whenever CompletionProposalPopup.fContentAssistSubjectControl is not null. But I can't see how that can come to pass, as ContentAssistSubjectControlAdapter#createCompletionProposalPopup would need a non-null ContentAssistSubjectControlAdapter#fContentAssistSubjectControl.
(In reply to Andreas Sewe from comment #5) > Now, that overload of ContentAssistant#computeCompletionProposals is called > whenever CompletionProposalPopup.fContentAssistSubjectControl is not null. > But I can't see how that can come to pass, as > ContentAssistSubjectControlAdapter#createCompletionProposalPopup would need > a non-null ContentAssistSubjectControlAdapter#fContentAssistSubjectControl. Neither can't Johannes. It thus seems impossible that control flows through ContentAssistant#computeCompletionProposals(IContentAssistSubjectControl, int); instead, we seem to go through ContentAssistant#computeCompletionProposals(ITextViewer, int) with the analysis in comment 4 being the most plausible. That must mean, however, that we are dealing with a IDocument, which returns something other than the DEFAULT_CONTENT_TYPE on IDocument#getContentType(int) or IDocumentExtension3#getContentType(String, int, booolean) when asked for the DEFAULT_PARTITIONING. Now, if the IDocument does not implement IDocumentExtension3, this seems most likely, because then the IDocument does not support multiple partitions and may not even recognize a value of DEFAULT_PARTITIONING.
The root problem (Bug 499980) has been fixed by the JDT team. I'm still keeping this bug open at the moment as "needinfo", as I would like to hear back from the people send the error reports where exactly they triggered Snipmatch to cause this problem, as it must be some kind of odd IDocument: (In reply to Andreas Sewe from comment #6) > That must mean, however, that we are dealing with a IDocument, which returns > something other than the DEFAULT_CONTENT_TYPE on > IDocument#getContentType(int) or IDocumentExtension3#getContentType(String, > int, booolean) when asked for the DEFAULT_PARTITIONING. Now, if the > IDocument does not implement IDocumentExtension3, this seems most likely, > because then the IDocument does not support multiple partitions and may not > even recognize a value of DEFAULT_PARTITIONING. FWIW, we *could* safeguard against this by asking the ITextViewer's IDocument about its #getLegalContentTypes or (if available) IDocumentExtension3#getLegalContentTypes(DEFAULT_PARTITIONING). If the latter is not supported and the former contains any other value than DEFAULT_PARTITIONING, we may run into this problem (in pre-Bug 499980 versions of o.e.jface.text) and should refrain from making any proposals. I don't think that's particularly appealing, though, as we may "over-block", i.e., not show proposals where we could.
(In reply to Andreas Sewe from comment #7) > FWIW, we *could* safeguard against this by asking the ITextViewer's > IDocument about its #getLegalContentTypes or (if available) > IDocumentExtension3#getLegalContentTypes(DEFAULT_PARTITIONING). If the > latter is not supported and the former contains any other value than > DEFAULT_PARTITIONING, we may run into this problem (in pre-Bug 499980 > versions of o.e.jface.text) and should refrain from making any proposals. > > I don't think that's particularly appealing, though, as we may "over-block", > i.e., not show proposals where we could. Based on discussion with Johannes, we decided to not do this. Unless the original reporters of this problem can provide us with the necessary details about the editor he used Snipmatch in, so that we can reproduce this issue, we won't implement a workaround but rather wait for the root caused being fix upstream (see Bug 499980). Thus, marking this bug as FIXED.
I unfortunately do not remember exactly how the issue happened and on what file, but the common file types I usually have open (99% of the time at least) are .java, .xtend and .xtext files, I'm assuming snipmatch will not be triggered on Xtext files so it the file is most probably Java. I don't know if Xtend files would also use snipmatch
(In reply to Ghaith Hachem from comment #9) > I unfortunately do not remember exactly how the issue happened and on what > file, but the common file types I usually have open (99% of the time at > least) are .java, .xtend and .xtext files, I'm assuming snipmatch will not > be triggered on Xtext files so it the file is most probably Java. > I don't know if Xtend files would also use snipmatch Thank you for the quick reply. Since Mars.2, Snipmatch supports files other than Java (although only with a limited, generic set of template variables like ${line_selection}), so you still could have triggered it there. That being said, AFAIK there are no snippets for files other than *.java shipped by default, so triggering Snipmatch in a *.xtend file doesn't do you much good -- unless you define your own snippets. Anyway, I will play around with Snipmatch in Xtext/Xtend files a bit; maybe I can recreate the issue.
(In reply to Andreas Sewe from comment #10) > Anyway, I will play around with Snipmatch in Xtext/Xtend files a bit; maybe > I can recreate the issue. Wasn't able to reproduce this, using Snipmatch in various locations in .xtend, .xtext and .mydsl (editor generated by Xtext) files.
