Community
Participate
Working Groups
In bug 266935 we have observed some strange behaviors in the way PDE is using the resolver State API. I have not investigated the PDE code paths enough to determine how this is happening, but the following two scenarios seem to be happening which cause the NPE mentioned in bug 266935 to happen: Scenario 1: 1) PDE is updating a BundleDescription (Xv1) to BundleDescription (Xv2) using State.updateBundle(Xv2) method. Where Xv1 and Xv2 both use the same Bundle ID (long). This is correct usage and is how PDE updates the state when a bundle in the workspace has a manifest change. 2) PDE is also removing BundleDescription (Xv1) from the State using State.removeBundle(Xv1) after it has updated it to Xv2. 3) A resolve operation is then performed on Xv2 which resulted in the NPE in bug 266935. I have not been able to reproduce this behavior in the wild but Aleksander Bandelj seems to have a setup which reproduces this reliably. Scenario 2: 1) PDE is configured to a target that has a number of bundles with the same BSN as a plug-in project in the workspace. When setting the active target to this target then the BundleDescriptions representing the bundles with the same BSN as the plug-in project in the workspace are removed from the state (using State.removeBundle(dupBSNs) 2) If the active target is then switched to another target ALL the BundleDescriptons representing the bundles in the target are removed including the descriptions that were removed in step 1. (not a big deal but this could be surfacing some of the strange behaviors we have encountered where "stale" descriptions are being removed after update in Scenario 1). I think there may be a subtle bug in PDE somewhere that is causing the model to contain some stale BundleDescriptions. Opening this bug so we can revisit the API usage patterns early in 3.6.
I'm being presumptuous by marking this as 3.6 since I am not on the PDE team but I really would like to see this investigated early in the next release ;-)
Marking this as 3.6 wasn't enough to keep this on the radar. I'll move it to RC1, but fixing this sounds rather involved.
(In reply to comment #2) > Marking this as 3.6 wasn't enough to keep this on the radar. I'll move it to > RC1, but fixing this sounds rather involved. I agree. This will likely will take a long time just to track down the incorrect usage. I would only spend time here if it looked like incorrect usage of the State was causing issues like bug309795 to happen.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
