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

Bug 438652

Summary: NPE when exporting a bundle with 'Deployable Plug-ins and Fragments'
Product: [Eclipse Project] Equinox Reporter: Hamid Nazari <hamid.nazari.hashemi>
Component: FrameworkAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: frank.benoit.ext, mail, markus.kell.r, michael.jaeger, Olivier_Thomann, thomascramera, tjwatson
Version: 3.10.0 Luna   
Target Milestone: Luna SR1   
Hardware: PC   
OS: Windows 8   
Whiteboard:
Attachments:
Description Flags
A simple plugin project to reproduce the exception
none
The exported plugin by Kepler SR2
none
A simple plugin project to reproduce the exception
none
The exported plugin by Kepler SR2
none
Patched plugin
none
Log for comment#18 none

Description Hamid Nazari CLA 2014-07-01 10:52:07 EDT
What steps will reproduce the problem?
1. Create a simple OSGi bundle (plugin project) with 'Bundle-NativeCode' header that has a clause with 'processor=x86' attribute for a native DLL.
2. Invoke Export->Deployable plug-ins and fragments' and try to export the bundle (no matter the settings on tabs)
3. The attached exception causes the operation to fail.

I've been using this feature since 2010 and had no problem with that so far, even with Kepler SR2 with Java 8 patch.
Note that this issue affects exporting ALL projects within a workspace, not only the project that has this definition in its manifest, that is, exporting any other project will fail even though their manifest has no Bundle-NativeCode header.

Also note that changing 'processor=x86' to 'processor=x86_64' allows the bundle be exported, but is not the intended workaround, of course. The same issue occurs if an short hand OS name is used, such as 'osname=Windows', but the stack trace will end at line 88 instead o line 120.

I must mention that I'm running eclipse on a x64-bit version of Java 1.8.0u5.
This has negative impact on my release since I want to use Luna's features but I'm struck at release because of this problem.

I'm looking forward for a patch/update on 'org.eclipse.osgi.compatibility.state' plugin or a proper workaround.


-- Error Details --
Date: Tue Jul 01 18:16:07 IRDT 2014
Message: An internal error occurred during: "Export Plug-ins".
Severity: Error
Product: Eclipse 4.4.0.20140612-0500 (org.eclipse.epp.package.jee.product)
Plugin: org.eclipse.core.jobs
Session Data:
eclipse.buildId=4.4.0.I20140606-1215
java.version=1.8.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product -data D:\Projects\Workspaces\Test

Exception Stack Trace:
java.lang.NullPointerException
	at org.eclipse.osgi.internal.resolver.NativeCodeSpecificationImpl.isSatisfiedBy(NativeCodeSpecificationImpl.java:120)
	at org.eclipse.osgi.internal.module.ResolverImpl.isResolvable(ResolverImpl.java:285)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles(ResolverImpl.java:639)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:477)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:545)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:605)
	at org.eclipse.pde.internal.build.site.BuildTimeSite.getRegistry(BuildTimeSite.java:186)
	at org.eclipse.pde.internal.build.BuildScriptGenerator.generateFeatures(BuildScriptGenerator.java:276)
	at org.eclipse.pde.internal.build.BuildScriptGenerator.generate(BuildScriptGenerator.java:127)
	at org.eclipse.pde.internal.core.exports.FeatureExportOperation.doExport(FeatureExportOperation.java:257)
	at org.eclipse.pde.internal.core.exports.FeatureBasedExportOperation.run(FeatureBasedExportOperation.java:50)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Comment 1 Thomas Watson CLA 2014-07-02 15:01:01 EDT
I can reproduce the NPE and can fix, but when I fix the code to get past the NPE then I always get an error exporting because it cannot resolve the Bundle-NativeCode dependency.  I then tried the same thing on Kepler and it fails with the same resolution error:

Processing inclusion from feature org.eclipse.pde.container.feature: Bundle nativeCode_1.0.0.qualifier failed to resolve.:
	Unsatisfied native code filter: foo.dll; processor=x86; osname=win32. 

Can you successfully export the bundle with no resolution errors?
Comment 2 Thomas Watson CLA 2014-07-02 15:02:35 EDT
Will look to fix the NPE for SR1, but please provide me with a simple project to reproduce and also state the expected outcome of export.  I assume a successful export producing a bundle jar is expected ;-).  But I cannot seem to do that even on Kepler.
Comment 3 Thomas Watson CLA 2014-07-02 15:51:59 EDT
I added a testcase to master with commit:

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=855ffcdb61166bd8a5f81e2ac004cfc93ccc583e

I fixed the NPE with commit:

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=84a00d87aa779a3d4dedca8d4ca429efecac5df9

But as I stated, this does not allow me to export the bundle successfully unless I change the target environment to be x86 instead of x86-64.

I will backport the fix once I understand more about the expected results.
Comment 4 Hamid Nazari CLA 2014-07-02 18:16:29 EDT
Created attachment 244755 [details]
A simple plugin project to reproduce the exception
Comment 5 Hamid Nazari CLA 2014-07-02 18:17:46 EDT
Created attachment 244756 [details]
The exported plugin by Kepler SR2
Comment 6 Hamid Nazari CLA 2014-07-02 18:42:43 EDT
Created attachment 244757 [details]
A simple plugin project to reproduce the exception

Changed the manifest to contain both osname and processor attributes for each clause
Comment 7 Hamid Nazari CLA 2014-07-02 18:43:22 EDT
Created attachment 244758 [details]
The exported plugin by Kepler SR2
Comment 8 Hamid Nazari CLA 2014-07-02 18:47:08 EDT
I've attached a simple plugin project to reproduce the issue in Luna. The same project exports without a problem in Kepler SR2 and I've attached the exported bundle, too. Note that this bundle has an activator that will try to load the DLL inside either for x86 or x64 arch and prints a success message.

About the error you mentioned getting earlier: it is true that attaching an inexact 'osname' attribute will result in an 'Unsatisfied native code filter'  during export (at least up to Kepler SR2), but using a correct osname will work this around. You got this error since you used 'win32' for osname, changing it to Windows8, for example, will fix the problem. I admit that this is also a bug and is not what OSGi specs state and interestingly enough for me Equinox resolves such bundle fine!

I think eclipse export must use the same logic employed by Equinox's resolver for this matter.
Comment 9 Markus Keller CLA 2014-07-04 06:14:08 EDT
POM version errors since http://download.eclipse.org/eclipse/downloads/drops4/N20140702-2000//pom_updates/ in
bundles/org.eclipse.osgi.compatibility.state/pom.xml
bundles/org.eclipse.osgi.tests/pom.xml
Comment 10 Michael Jaeger CLA 2014-07-08 06:41:14 EDT
I am not able to export new versions of my product.  Do you recommend to switch back to 4.3 because this issue will take a while to get fixed?  I am a little bit surprised that a function that vital is not working in a final release...
Comment 11 Thomas Watson CLA 2014-07-08 17:09:59 EDT
(In reply to Michael Jaeger from comment #10)
> I am not able to export new versions of my product.  Do you recommend to
> switch back to 4.3 because this issue will take a while to get fixed?  I am
> a little bit surprised that a function that vital is not working in a final
> release...

I don't have a workaround to recommend to you for 4.4.  It will be fixed for 4.4 SR1 which will be released in September [1].  The eclipse/equinox project will have test builds available earlier for you to test, but an actual release with the fix will not be done before September.  Once we have a fix to test it may be possible for you to patch 4.4 yourself until we have an SR1 release.

[1] http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#SR1
Comment 12 Thomas Watson CLA 2014-07-08 17:26:29 EDT
(In reply to Hamid Nazari from comment #8)
> I've attached a simple plugin project to reproduce the issue in Luna. The
> same project exports without a problem in Kepler SR2 and I've attached the
> exported bundle, too. Note that this bundle has an activator that will try
> to load the DLL inside either for x86 or x64 arch and prints a success
> message.
> 
> About the error you mentioned getting earlier: it is true that attaching an
> inexact 'osname' attribute will result in an 'Unsatisfied native code
> filter'  during export (at least up to Kepler SR2), but using a correct
> osname will work this around. You got this error since you used 'win32' for
> osname, changing it to Windows8, for example, will fix the problem. I admit
> that this is also a bug and is not what OSGi specs state and interestingly
> enough for me Equinox resolves such bundle fine!
> 
> I think eclipse export must use the same logic employed by Equinox's
> resolver for this matter.

Thanks.  I'm using Windows 7 and I cannot get this bundle to export successfully for me with 4.3.x eclipse (Kepler).  It does get the expected NPE with 4.4.0 (Luna).  The fix released for the Mars I-Build does fix the NPE for me, but then the bundle still fails to export for me the same as in Kepler.  Could you try this out with the latest 4.5 integration build?

http://download.eclipse.org/eclipse/downloads/
Comment 13 Thomas Watson CLA 2014-07-09 10:56:16 EDT
backported to Luna maintenance branch with commits:

Test:
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=0daf037d3b387b111df9761b127b1e7c079a1919

Fix:
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=e4a0d3fdc8aacb47eab2634f7c5286667b75cef0

Increment version in poms:
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=150ea3742bcf40f0010eb205819faef861327e65

Changing the Bundle-NativeCode to use Windows7 allowed me to export.  I am assuming that is how you get this to work also.  Closing as fixed.  It does not look like this made it in time for the M-Build today but should be in next weeks for testing.
Comment 14 Hamid Nazari CLA 2014-07-11 17:11:12 EDT
Created attachment 245010 [details]
Patched plugin

I've managed to patch the original plugin with ASM based on you fix. Replacing it with the one in 'plugins' folder of my eclipse installation fixed my issue and allowed a successful export. I'll stick with this one for the time being. I'm sharing it with anyone willing to have the fix before its included in an integration build. Note that it is an unsigned JAR and use it at your own risk.
Comment 15 Vikas Chandra CLA 2014-08-26 09:55:58 EDT
*** Bug 435407 has been marked as a duplicate of this bug. ***
Comment 16 Curtis Windatt CLA 2014-09-18 14:43:22 EDT
*** Bug 444509 has been marked as a duplicate of this bug. ***
Comment 17 Andy Thomas-Cramer CLA 2014-10-07 16:40:48 EDT
With 4.4.1, the NPE occurs for me with the OP's attached example project, modified to require Java 7 and use osname=win32 instead of osname=Windows (which resulted in a complaint that it could not be satisfied).

Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-NativeCode: library/x86/foo.dll;processor=x86;osname=win32,library/x64/foo.dll;processor=x86_64;osname=win32

Works fine in 4.3.2, throws NPE in 4.4.1.
Comment 18 Andy Thomas-Cramer CLA 2014-10-07 17:37:56 EDT
And still occurs for me in 4.4.1 with the OP's attached project unmodified. 

Environment: Windows 8.1. Eclipse 4.4.1 running on Java 8, with Java 8
Comment 19 Thomas Watson CLA 2014-10-08 08:58:48 EDT
(In reply to Andy Thomas-Cramer from comment #18)
> And still occurs for me in 4.4.1 with the OP's attached project unmodified. 
> 
> Environment: Windows 8.1. Eclipse 4.4.1 running on Java 8, with Java 8

Please provide the log with the stacktrace.
Comment 20 Andy Thomas-Cramer CLA 2014-10-08 10:31:48 EDT
Created attachment 247721 [details]
Log for comment#18

Attached is the full log from the start of a session to File>Export; Plug-in Development>Deployable plug-ins and fragments.

Below is the last message from that log.

!ENTRY org.eclipse.core.jobs 4 2 2014-10-08 09:27:45.752
!MESSAGE An internal error occurred during: "Export Plug-ins".
!STACK 0
java.lang.NullPointerException
	at org.eclipse.osgi.internal.resolver.NativeCodeSpecificationImpl.isSatisfiedBy(NativeCodeSpecificationImpl.java:88)
	at org.eclipse.osgi.internal.module.ResolverImpl.isResolvable(ResolverImpl.java:285)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles(ResolverImpl.java:639)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:477)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:545)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:605)
	at org.eclipse.pde.internal.build.site.BuildTimeSite.getRegistry(BuildTimeSite.java:186)
	at org.eclipse.pde.internal.build.BuildScriptGenerator.generateFeatures(BuildScriptGenerator.java:276)
	at org.eclipse.pde.internal.build.BuildScriptGenerator.generate(BuildScriptGenerator.java:127)
	at org.eclipse.pde.internal.core.exports.FeatureExportOperation.doExport(FeatureExportOperation.java:257)
	at org.eclipse.pde.internal.core.exports.FeatureBasedExportOperation.run(FeatureBasedExportOperation.java:50)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Comment 21 Andy Thomas-Cramer CLA 2014-10-08 10:32:29 EDT
In case it matters, this is on a 64-bit machine with a 32-bit Eclipse IDE.
Comment 22 Thomas Watson CLA 2014-10-08 11:57:53 EDT
In the log it indicates:

eclipse.buildId=4.4.0.I20140606-1215

This is 4.4.0.  Where did you download 4.4.1 from?  Are you certain you updated successfully?
Comment 23 Andy Thomas-Cramer CLA 2014-10-08 13:52:32 EDT
I am running 4.4.1, according to the "About Eclipse" box on both my Windows and Mac installs. Details:

  Eclipse for RCP and RAP Developers

  Version: Luna Service Release 1 (4.4.1)
  Build id: 20140925-1800

I obtained this after the 4.4.1 release last month (probably obtained Oct. 3), from http://www.eclipse.org/downloads/ following the links for "Eclipse for RCP and RAP Developers". 

I don't know why the 4.4.1 release is showing that buildID in the log, but the IDE itself is showing the version and buildID above.

I am currently using a 4.4.0 target platform in the 4.4.1 IDE.
Comment 24 Thomas Watson CLA 2014-10-08 16:32:33 EDT
(In reply to Andy Thomas-Cramer from comment #23)
> I am running 4.4.1, according to the "About Eclipse" box on both my Windows
> and Mac installs. Details:
> 
>   Eclipse for RCP and RAP Developers
> 
>   Version: Luna Service Release 1 (4.4.1)
>   Build id: 20140925-1800
> 
> I obtained this after the 4.4.1 release last month (probably obtained Oct.
> 3), from http://www.eclipse.org/downloads/ following the links for "Eclipse
> for RCP and RAP Developers". 
> 
> I don't know why the 4.4.1 release is showing that buildID in the log, but
> the IDE itself is showing the version and buildID above.
> 
> I am currently using a 4.4.0 target platform in the 4.4.1 IDE.

Something seems off with your installation.  Can you bring up the osgi console and run the command:

osgi> ss | grep osgi

Or if it is not obvious how to get the OSGi console then go to Help -> About Eclipse -> Installation Details (button) -> Plug-ins (tab)

Check the version of the plugins (bundles) with the Ids: org.eclipse.osgi and org.eclipse.osgi.compatibility.state

I would expect the following versions:

org.eclipse.osgi version 3.10.1.v20140909-1633
org.eclipse.osgi.compatibility.state version 1.0.1.v20140709-1414
Comment 25 Andy Thomas-Cramer CLA 2014-10-09 17:03:16 EDT
From Help>About; Installation Details button; Plug-ins tab (versions copied by hand):
* org.eclipse.osgi: 3.10.0.v201406061445
* org.eclipse.osgi.compatibility.state: 1.0.0.v20140403-1907

These are not the versions you said should be expected.

Let me try this in a clean, newly-downloaded IDE, without adding any additional plug-ins.
Comment 26 Andy Thomas-Cramer CLA 2014-10-10 16:49:47 EDT
@Thomas Watson, you nailed it. 

It was the 4.4.1 build, but I had used "Help>Install New Software" to install extensions from the e4 updates at http://download.eclipse.org/e4/updates/0.16. These are in incubation state. 

The two below installed older versions of at least the plug-ins you asked about. 
* Eclipse 4 - 3.x bridge
* Eclipse 4 - Model Spy

My comment#17 is invalid. This defect no longer occurs in 4.4.1 for me either, given an install without those extensions. My lesson for the day is to try it in a clean install before complaining. 

Thank you for being very perceptive and helpful.
Comment 27 Thomas Watson CLA 2014-10-13 08:57:29 EDT
(In reply to Andy Thomas-Cramer from comment #26)
> @Thomas Watson, you nailed it. 
> 
> It was the 4.4.1 build, but I had used "Help>Install New Software" to
> install extensions from the e4 updates at
> http://download.eclipse.org/e4/updates/0.16. These are in incubation state. 
> 
> The two below installed older versions of at least the plug-ins you asked
> about. 
> * Eclipse 4 - 3.x bridge
> * Eclipse 4 - Model Spy

I don't like the sounds of this at all.  It seems really strange that installing some extensions from e4 update site would downgrade equinox.  Perhaps open a bug against e4 incubator on that?

> 
> My comment#17 is invalid. This defect no longer occurs in 4.4.1 for me
> either, given an install without those extensions. My lesson for the day is
> to try it in a clean install before complaining. 
> 
> Thank you for being very perceptive and helpful.

No problems.  Glad we got to the bottom of it.
Comment 28 Andy Thomas-Cramer CLA 2014-10-13 11:22:08 EDT
>I don't like the sounds of this at all.  It seems really strange that installing some extensions from e4 update site would downgrade equinox.  Perhaps open a bug against e4 incubator on that?

Added Bug 446932 - Some e4 updates tools installed in 4.4.1 IDE downgrade parts of it to 4.4.0 (edit)