Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324473

Summary:

NPE in resolver breaking classpath computation

Product:

[Eclipse Project] Equinox

Reporter:

John Arthorne <john.arthorne>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

RESOLVED FIXED

QA Contact:

Severity:

critical

Priority:

CC:

ralf, tjwatson

Version:

3.6

Target Milestone:

3.7 M2

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Log file	none
patch + test	none

Description John Arthorne

2010-09-03 14:19:17 EDT

I20100831

I got into a state today where Eclipse crashed, and could not be restarted. After deleting workbench.xml I was able to start, but anything I attempted to do was causing more errors. I eventually had to revert to an earlier build. I will attach the complete stack, but the NPE looks like this:

java.lang.NullPointerException
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireGeneric(ResolverImpl.java:184)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundle(ResolverImpl.java:169)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireImport(ResolverImpl.java:232)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundle(ResolverImpl.java:164)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireImport(ResolverImpl.java:232)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundle(ResolverImpl.java:164)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireImport(ResolverImpl.java:232)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundle(ResolverImpl.java:164)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireRequire(ResolverImpl.java:207)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundle(ResolverImpl.java:159)
	at org.eclipse.osgi.internal.module.ResolverImpl.rewireBundles(ResolverImpl.java:148)
	at org.eclipse.osgi.internal.module.ResolverImpl.initialize(ResolverImpl.java:118)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:394)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:468)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:531)
	at org.eclipse.pde.internal.core.MinimalState.internalResolveState(MinimalState.java:226)
	at org.eclipse.pde.internal.core.MinimalState.resolveState(MinimalState.java:201)
	at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:541)
	at org.eclipse.pde.internal.core.PluginModelManager.findModel(PluginModelManager.java:892)
	at org.eclipse.pde.core.plugin.PluginRegistry.findModel(PluginRegistry.java:110)
	at org.eclipse.pde.internal.core.RequiredPluginsInitializer.initialize(RequiredPluginsInitializer.java:31)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2709)

Comment 1 John Arthorne

2010-09-03 14:19:56 EDT

Created attachment 178186 [details]
Log file

Comment 2 John Arthorne

2010-09-03 14:34:14 EDT

This looks like a new regression in the resolver. Here is the code:

if (namespace == null) {
	System.err.println("Could not find matching capability for " + constraint.getVersionConstraint()); //$NON-NLS-1$
	// TODO log error!!
}
String constraintName = constraint.getName();
GenericCapability[] matches = constraintName == null ? 
	namespace.get(constraintName) : 
	namespace.getAllValues();

The NPE occurs on the last line, due to "namespace" being null. It is clearly checking for null on namespace just above, but it doesn't do anything about it! So, the NPE happens immediately afterwards.

Comment 3 Thomas Watson

2010-09-05 16:27:53 EDT

running with -clean should also fix the situation.  But only temporarily.  Anytime a resolve operation is needed you will hit this bug again.  I got a fix and testcase I will attach.

Comment 4 Thomas Watson

2010-09-05 16:33:11 EDT

Created attachment 178231 [details]
patch + test

The NPE is a side-effect of a different bug.  Resolved fragments that provide capabilities must provide their capabilities from their hosts.  The resolver was not handling this correctly which caused the capabilities provided by the fragments to get dropped when the resolver got initialized.

I updated the fragment test to force a re-resolve from a cached state.

Comment 5 Thomas Watson

2010-09-05 16:41:04 EDT

Patch released.  I also updated the cached state meta-data version which forces the state to be reconstructed.  This should allow us to upgrade from last weeks build to this weeks build without a -clean.

Comment 6 Thomas Watson

2010-09-05 16:47:44 EDT

*** Bug 324536 has been marked as a duplicate of this bug. ***