Community
Participate
Working Groups
Build Identifier: 3.6.1.R36x_v20100806 During our automated integration tests we are seeing an occasional failure to start bundles in equinox. This seems to happen on average about one run in fifty on our test hardware. exec] Caused by: org.osgi.framework.BundleException: The state indicates the bundle is resolved [exec] at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1300) [exec] at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:319) [exec] at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) [exec] at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:276) Once the framework is in this state the only route out seems to be a framework restart. The sequence of events is the same in each run, it basically involves installing groups of bundles and starting some of these bundles. We call PackageAdmin.refresh at several intervals to ensure the bundle wiring is correct. We also see the following NPE - though at a lesser frequency so it may or may not be related. Caused by: java.lang.NullPointerException [exec] at org.eclipse.osgi.internal.loader.BundleLoader.createExportPackageSource(BundleLoader.java:273) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.getImportedSources(BundleLoader.java:248) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findImportedSource(BundleLoader.java:1058) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) [exec] at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) [exec] at java.lang.ClassLoader.loadClass(ClassLoader.java:248) [exec] at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338) [exec] at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232) [exec] at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:149) [exec] ... 181 more We also have code to log framework events and I found this which happens each time we see the NPE: ERROR [Framework Event Dispatcher] org.eclipse.osgi:3.6.1.R36x_v20100806 org.osgi.framework.BundleException: The bundle does not exist in the framework: com.paremus.XXX at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.setResolved(PackageAdminImpl.java:368) ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.applyDeltas(PackageAdminImpl.java:396) ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:486) ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:239) ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] at java.lang.Thread.run(Thread.java:619) ~[na:1.6.0_20] This feels like a race condition as it happens infrequently but it's a little difficult to tell. If there are any further diagnostics I can run to help figure out what this problem is I'm happy to add them to our integration tests. Reproducible: Sometimes Steps to Reproduce: 1. Install a number of bundles 2. Start some of them 3. Occasionally call PackageAdmin.refresh
(In reply to comment #0) > Build Identifier: 3.6.1.R36x_v20100806 > > During our automated integration tests we are seeing an occasional failure to > start bundles in equinox. This seems to happen on average about one run in > fifty on our test hardware. > > exec] Caused by: org.osgi.framework.BundleException: The state indicates the > bundle is resolved > [exec] at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1300) > [exec] at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:319) > [exec] at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) > [exec] at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:276) > > Once the framework is in this state the only route out seems to be a framework > restart. > > The sequence of events is the same in each run, it basically involves > installing groups of bundles and starting some of these bundles. We call > PackageAdmin.refresh at several intervals to ensure the bundle wiring is > correct. > If you try to start the bundle again does it still fail? I can see how this may happen if you attempt to start an unresolved bundle that is unresolvable in one thread, but then install some more bundles and cause a resolution operation in another thread (refresh packages thread). So the start attempts to resolve the bundle, but it cannot at that moment because the dependencies have not been installed, then the other thread installs the dependencies and causes a resolve before we can obtain the resolution error from the first resolution attempt. If this is happening then I suspect the a second start of the bundle should succeed, because it should be resolved at that point.
(In reply to comment #0) > We also see the following NPE - though at a lesser frequency so it may or may > not be related. > > Caused by: java.lang.NullPointerException > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.createExportPackageSource(BundleLoader.java:273) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.getImportedSources(BundleLoader.java:248) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.findImportedSource(BundleLoader.java:1058) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) > [exec] at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) > [exec] at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > [exec] at > org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338) > [exec] at > org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232) > [exec] at > org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:149) > [exec] ... 181 more > > We also have code to log framework events and I found this which happens each > time we see the NPE: > > ERROR [Framework Event Dispatcher] org.eclipse.osgi:3.6.1.R36x_v20100806 > org.osgi.framework.BundleException: The bundle does not exist in the framework: > com.paremus.XXX > at > org.eclipse.osgi.framework.internal.core.PackageAdminImpl.setResolved(PackageAdminImpl.java:368) > ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] > at > org.eclipse.osgi.framework.internal.core.PackageAdminImpl.applyDeltas(PackageAdminImpl.java:396) > ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] > at > org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:486) > ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] > at > org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:239) > ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] > at > org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) > ~[org.eclipse.osgi_3.6.1.R36x_v20100806.jar:na] > at java.lang.Thread.run(Thread.java:619) ~[na:1.6.0_20] > > This feels like a race condition as it happens infrequently but it's a little > difficult to tell. > yeah, it sure looks like it. But can you tell me if you are uninstalling bundles or perhaps updating them during this test?
I'm closing as worksforme. Not because I think the old code base does not have a real bug. Instead because the luna release did major restructuring of the core framework to make it more thread safe and this type of error should no longer occur.
