Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 325883 - Dynamic import resolver bug
Summary: Dynamic import resolver bug
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.5.1   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 major (vote)
Target Milestone: 3.5.2+   Edit
Assignee: equinox.framework-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 324618 325885
Blocks:
  Show dependency tree
 
Reported: 2010-09-21 14:14 EDT by Jeff McAffer CLA
Modified: 2010-09-21 14:16 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff McAffer CLA 2010-09-21 14:14:55 EDT 
+++ This bug was initially created as a clone of Bug #324618 +++

A customer has observed some strange behaviour in the Equinox resolver (version 3.5.1.R35x_v20091005) and has spotted some code which may be to blame.

ResolverImpl line 1561 is:

resolverImports[j].setPossibleSuppliers(null))

rather than:

resolverImports[j].clearPossibleSuppliers()

and so possibleSuppliers in the array member is set to null, but selectedSupplierIndex is not set to 0 as well.

They say that, upon debugging, they ran into an issue where, in ResolverConstraint.selectNextSupplier(), the selectedSupplierIndex is not reset to 0 and, even if possibleSuppliers has values, selectNextSupplier returns false because selectedSupplierIndex is 1 (because it was not reset in the past) and possibleSuppliers.length is 1.

We don't have a (simple) testcase to reproduce, or indeed any way of reproducing the behaviour the customer consistently observes.

Assigning to Tom as he has already started to look at this.
Comment 1 Jeff McAffer CLA 2010-09-21 14:15:56 EDT 
The patches and tests from the original bug have been backported to 3.5.x