Bugzilla – Full Text Bug Listing
| Summary: | NPE after running JUnit Plugin Test | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Tyler Smith <smith.d.tyler> | ||||
| Component: | Automated Error Reporting Client (AERI) | Assignee: | EPP Error Reports <error-reports-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | bsd, marcel.bruch, sewe, simon.laffoy, smith.d.tyler, Vikas.Chandra | ||||
| Version: | 4.5.0 | Keywords: | triaged | ||||
| Target Milestone: | 4.6.0RC2 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=488917 https://git.eclipse.org/r/67798 https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/commit/?id=c6ce9f27af44ffd8a28e1153140a61a7d15d3f32 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The source of this exception is
@Override
public Object invoke(Object object, Class<? extends Annotation> qualifier, PrimaryObjectSupplier objectSupplier) {
Object result = invokeUsingClass(object, object.getClass(), qualifier, IInjector.NOT_A_VALUE, objectSupplier, null, true);
if (result == IInjector.NOT_A_VALUE) {
if (object != null && qualifier != null) {
throw new InjectionException("Unable to find matching method to invoke. Searching for the annotation \"" + qualifier.toString() + "\" on an instance of \"" + object.getClass().getSimpleName() + "\""); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
}
throw new InjectionException("Unable to find matching method to invoke. One of the arguments was null."); //$NON-NLS-1$
}
return result;
}
From org.eclipse.e4.core.di.source_1.5.0.v20150421-2214.jar/org.eclipse.e4.core.internal.di/InjectorImpl.java.
When the error occurs, the 'object' variable is null. This appears to be a coding error, since object is checked for null *after* it is dereferenced.
Moving to Platform IDE Looks like AERI's logging is getting into recursion trying to log an OSGi-delivered logging message to the Platform logger, which then logs out via an OSGi logger. This sounds like the situation I described in bug 358968#c12: logging to the platform logger results in a new log message on the LogReaderService. I managed to dig up my old code that sought to forward OSGi logging messages to the Platform logger. My OSGi LogListener had to check that the log entry is a ExtendedLogEntry AND that the ExtendedLogEntry's context is not itself a FrameworkLogEntry — that seemed a fairly sure heuristic that the LogEntry was from the Platform log. private class NormalLogListener implements LogListener { private LogReaderService lrs; public NormalLogListener(LogReaderService lrs) { this.lrs = lrs; } public void logged(LogEntry entry) { // writes to the Eclipse log (such as by our slf4j -> Eclipse log) // are then re-logged through the OSGi LogService if (!(entry instanceof ExtendedLogEntry && ((ExtendedLogEntry) entry).getContext() instanceof org.eclipse.osgi.framework.log.FrameworkLogEntry)) { logEntry(lrs, entry); } } } I'm able to reproduce but did not find a fix yet. It looks like a concurrency problem where some variables are not visible to other threads but I need to dive in deeper. Workaround: Specify a system property via "‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true" in the launch configuration. This will return quickly in SystemControl#isActive - before the problematic code. *** Bug 488917 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/67798 Gerrit change https://git.eclipse.org/r/67798 was merged to [master]. Commit: http://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/commit/?id=c6ce9f27af44ffd8a28e1153140a61a7d15d3f32 This bug occurs on workbench shutdowns when the AERI EclipseContext is disposed but the Platform still sends log events to the error log. In that case AERI's context get's disposed by Eclipse which clears all its internal state which, in turn, leads to the NPE you reported. Thank you for providing the test scenario. (In reply to Eclipse Genie from comment #7) > Gerrit change https://git.eclipse.org/r/67798 was merged to [master]. This change is available on the milestones update site [1] for further testing. Please update your Eclipse installation or target platform to get rid of this problem. In case you cannot update, you can: 1. disable AERI plugins in you Eclipse Runtime launch configuration, or 2. set the system property as mentioned above. Thanks, Marcel [1] http://download.eclipse.org/technology/epp/logging/milestones/ *** Bug 487192 has been marked as a duplicate of this bug. *** |
Created attachment 260051 [details] Full Stack Trace and Installation Details I'm running Eclipse Mars (4.5.2) with a few additional plugins installed (full Manifest attached). I created a new Plugin project and added a single test case: import org.junit.Test; public class SimpleTest { @Test public void doNothingTest(){ System.out.println("Nothing to see here..."); } } When I run this test as a JUnit Plugin Test, it passes, but I get this error printed to the console: !ENTRY org.eclipse.epp.logging.aeri.core 2 1 2016-03-02 07:04:33.285 !MESSAGE AERI failed with an error. Please report this error: null ; version: 1.100.0.v20160211-1103 !STACK 0 java.lang.NullPointerException at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:217) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:90) at org.eclipse.epp.logging.aeri.core.SystemControl.executeHandler(SystemControl.java:103) at org.eclipse.epp.logging.aeri.core.SystemControl.isActive(SystemControl.java:65) at org.eclipse.epp.logging.aeri.core.util.LogListener.logging(LogListener.java:45) at org.eclipse.core.internal.runtime.RuntimeLog.logToListeners(RuntimeLog.java:161) at org.eclipse.core.internal.runtime.PlatformLogWriter.logged(PlatformLogWriter.java:103) at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:88) at This continues for quite a while. Full trace is attached. My installation details are included in the attachment.