Closed HannesWell closed 2 years ago
Does clearing out our configuration/org.eclipse.osgi
framework storage area help get past this? Running with -clean does this.
Although I'm a maintainer of Felix SCR, I must admit that I am not that familiar with how this "SCR Component Actor" thread is used. From looking at the code it seems that it does async work for calls to org.osgi.service.component.ComponentContext.enableComponent(String)
or org.osgi.service.component.runtime.ServiceComponentRuntime.enableComponent(ComponentDescriptionDTO)
. It would appear there is some cycle in the components and we have enableComponent
getting called in this scenario.
As to the locks on org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse
we had a similar bug in https://bugs.eclipse.org/bugs/show_bug.cgi?id=544583. I doubt it got addressed by SCR in any way. Perhaps we could change that to use a ReentrantLock so we can introduce timeout? But it gets tricky to come up with an acceptable default timeout. I'm sure someone has a crazy design that does in-determinant blocking out of their ServiceFactory
by design. In the end, I don't believe this to actually be a framework bug. By spec we are obligated to call the ServiceFactory
while holding a lock to guarantee multiple threads do not call it in parallel.
Does clearing out our
configuration/org.eclipse.osgi
framework storage area help get past this? Running with -clean does this.
Yes! After adding -clean
as program-argument in the ini that Eclipse starts flawlessly. Before that the problem constantly occurred in each launch. So without that it was effectively unusable. I worked around this in the meantime by remote debugging that Eclipse with another one and blocked the SCR-theard before it could acquire the uses lock to avoid the dead-lock. But this is of course very inconvenient and not applicable for the standard Eclipse user.
Thank you Tom for the work-around. However I suggest to fix that issue in Equinox or Felix and keep this open until then.
You can also provoke a lock if you do the following:
Even though the Spec warns about that case, I would have expected that in this case the service tracker simply remains empty unless the activator has started. Maybe this would be a simpler case to debug such blocking?
I worked around this in the meantime by remote debugging that Eclipse with another one and blocked the SCR-theard before it could acquire the uses lock to avoid the dead-lock.
Do you remember where you blocked the SCR? It might then be that the locking has some dead-lock (e.g. locking in the wrong order or something), I took a quick look at the code in ServiceRegistrationImpl
but it seems rather complex to take a guess by just looking at the code.
So if you can describe what are the code path to maybe provoke the lock (e.g. if Thread A is on line X and then Thread B calls Y), that would help I think.
I'm sure someone has a crazy design that does in-determinant blocking out of their
ServiceFactory
by design.
Looking at the stack trace I don't see anything 'crazy' at least the only non framework WorkspaceInitCustomizer
so not perform any blocking at that point, just calling registerService
from within a ServiceTrackerCustomizer
...
Although I'm a maintainer of Felix SCR, I must admit that I am not that familiar with how this "SCR Component Actor" thread is used. From looking at the code it seems that it does async work for calls to
org.osgi.service.component.ComponentContext.enableComponent(String)
ororg.osgi.service.component.runtime.ServiceComponentRuntime.enableComponent(ComponentDescriptionDTO)
. It would appear there is some cycle in the components and we haveenableComponent
getting called in this scenario.
I share the assumption that there are some DS-components that reference each other and are created in opposite order by the SCR-thread and the main thread..
As to the locks on
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse
we had a similar bug in https://bugs.eclipse.org/bugs/show_bug.cgi?id=544583. I doubt it got addressed by SCR in any way. Perhaps we could change that to use a ReentrantLock so we can introduce timeout? But it gets tricky to come up with an acceptable default timeout. I'm sure someone has a crazy design that does in-determinant blocking out of theirServiceFactory
by design. In the end, I don't believe this to actually be a framework bug. By spec we are obligated to call theServiceFactory
while holding a lock to guarantee multiple threads do not call it in parallel.
That bug sounds similar to the one I encountered. What's interesting is that another Eclipse-installation on the same computer that is based on the same Eclipse milestone but with a few different plug-ins (i.e. Eclipse-for-Eclipse-committers from Oomph) did not face the problem. And after one clean-start the problem is now gone completely (I restarted it several times now). Before that it constantly appeared. So I suspect certain configurations/saved states provoke the error.
I'm also absolutely not familiar about the Felix-SCR code. But I would only add a time-out as last resort, because as you said: It is hard to find a good default that fits for everybody. And a user/downstream-consumer should not have to tweak settings to hopefully be able to successfully start the application. And if this dead-lock happens often this can also delay the application start for so long that the application at least appears to be hung up.
If I understand it correctly Equinox holds locks for each service-object under construction?
Maybe Felix can track the components under construction in a ConcurrentHashMap.keySet()
and can detect cycles that lead to dead-locks? Simply spoken it adds a unique proxy of the component in a 'components-being-constructed'-set and if that proxy is already present stops the construction of the current component and all others that depend on it and discards all of them. It would then just restart from the root again. The other thread could then continue its construction and the first one will likely find some already constructed components in its second attempt.
Thanks for that example.
I worked around this in the meantime by remote debugging that Eclipse with another one and blocked the SCR-theard before it could acquire the uses lock to avoid the dead-lock.
Do you remember where you blocked the SCR? It might then be that the locking has some dead-lock (e.g. locking in the wrong order or something), I took a quick look at the code in
ServiceRegistrationImpl
but it seems rather complex to take a guess by just looking at the code.
I put a break-point here: https://github.com/eclipse-equinox/equinox.framework/blob/041df92ef3032edc14a8552aa7a2927f2e743d7c/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/serviceregistry/ServiceRegistrationImpl.java#L538
I suspect that there is one use/servicesInUse
per service object in construction and if there are objects referencing each other and in case they are constructed in different order by different threads the deadlock occurs.
So if you can describe what are the code path to maybe provoke the lock (e.g. if Thread A is on line X and then Thread B calls Y), that would help I think.
Stupidly I immediately cleaned the Eclipse installation and didn't copy it before to reproduce the issue later, so unfortunately I cannot reproduce the issue. But maybe it is possible to construct one from the description of cyclic components above.
I must confess I'm a bit curious if it is really a circular dependency. Why should it be not circular once you clear some state? Beside that Felix reports circular dependencies as far as I know, and won't start them so now you should see some components being unsatisfied...
My guess is that the start-order triggers the issue. When doing updates the updated bundles get larger bundle IDs so they end up getting started later (p2 does an uninstall-old, install-new bundle instead of update which would reuse the old bundle id). When you do -clean we start over and the bundles are installed by p2 ordered by the symbolic name (I think).
p2 does an uninstall-old, install-new bundle instead of update
I also noticed some issues with this behavior e.g. when a bundle contains native code ... is there any reason for this behavior?
My guess is that the start-order triggers the issue.
But should the start-order not be irrelevant in case of service handling? So this is actually a framework issue and not a "user" issue?
I also noticed some issues with this behavior e.g. when a bundle contains native code ... is there any reason for this behavior?
I imagine because of the location. From the osgi>
console run lb -l
to see the locations like this: reference:file:plugins/org.eclipse.swt_3.120.0.v20220525-1003.jar
But should the start-order not be irrelevant in case of service handling? So this is actually a framework issue and not a "user" issue?
I cannot tell what you mean by the first sentence ... but: The type of cycle that would cause issues is something like this:
A -> B -> (optional, dynamic, reference) -> C C -> A
Assume each service component A, B, C come from a separate bundle and the start-order is A, B, C. Once B is started it will allow A to be satisfied. B can be satisfied without C's bundle being active yet so now A and B can be constructed and activated by SCR. Once C's bundle is activated it can now also be satisfied by A and be dynamically injected into B. On the other hand if C's bundle is started first then it comes into play as soon as possible which could trigger some crossing of paths while constructing the service instances by SCR. This is not a framework issue. I would think this is more of an SCR issue.
I cannot tell what you mean by the first sentence
I mean that, regardless of order, the framework should never "deadlock", e.g. even if there is a cycle (how?) between services?
This is not a framework issue. I would think this is more of an SCR issue.
Is it forbidden to call BundleContext#getService
from an arbitrary thread? Because this seems where the deadlock occurs, so if the framework is actually busy doing other tasks, I would assume the BundleContext#getService
simply blocks, but never dead-lock in any way?
Is it forbidden to call
BundleContext#getService
from an arbitrary thread? Because this seems where the deadlock occurs, so if the framework is actually busy doing other tasks, I would assume theBundleContext#getService
simply blocks, but never dead-lock in any way?
It is not forbidden. Only thing I can think of to "make this better" is to detect the deadlock somehow and throw a ServiceException immediately. But I don't see an obvious way to do that reliably.
But I don't see an obvious way to do that reliably.
There are too many locks involved :-\
I really wonder why we need such a complex ServiceUse
to track the use-count, won't a AtomicInteger
also serve the purpose?
I really wonder why we need such a complex
ServiceUse
to track the use-count, won't aAtomicInteger
also serve the purpose?
Not sure, but that is unrelated to the deadlock. The lock is required by the specification to ensure more than one thread does not enter ServiceFactory.getService to construct the service instance.
Not sure, but that is unrelated to the deadlock.
At least both treads compete for locking the ServiceUse :-)
The lock is required by the specification to ensure more than one thread does not enter ServiceFactory.getService to construct the service instance.
right but if @HannesWell could make it work by holding one thread with the debugger to enter the critical section, then it seems there is something wrong here in how this locking works (e.g. there is a solution and the lock is not inevitable), but I don't have a good idea yet how to circumvent this without a reproducing test-case or description why the deadlock occurs, I have poked a bit around in the Felix code but it seems there are no more locks involved and I haven't found any waits yet that explain this behavior.
Stupidly I immediately cleaned the Eclipse installation and didn't copy it before to reproduce the issue later,
Any chance you know the version of eclipse you upgraded from? As the ResourcePlugin is involved, I think it might be an update of some of the "core-ide" bundles and fear other users might run into the same issue as well on the next release, so if we can find a solution here (even if it will not make it into this release) I think it would be very helpful.
The lock is required by the specification
Just wondering, is there a TCK that check this particular requirement so we can change here without the fear of breaking things?
Stupidly I immediately cleaned the Eclipse installation and didn't copy it before to reproduce the issue later,
Any chance you know the version of eclipse you upgraded from? As the ResourcePlugin is involved, I think it might be an update of some of the "core-ide" bundles and fear other users might run into the same issue as well on the next release, so if we can find a solution here (even if it will not make it into this release) I think it would be very helpful.
It is the Eclipse Modeling Tools
Oomph Product in version latest
. Since I perform the setup tasks regularly I strongly assume it was 2022-06 M2 and upgraded to M3. The catalog-update to 2022-06 M3 was made available yesterday (commit 2111114185024bba9c38177f8bd137d3670e867f in the Oomph repo).
Additionally I used the following P2Director task which installs the corresponding features:
<?xml version="1.0" encoding="UTF-8"?>
<setup.p2:P2Task
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0"
label="Development Requirements">
<requirement
name="org.eclipse.xtext.sdk.feature.group"/>
<requirement
name="org.eclipse.emf.ecore.xcore.sdk.feature.group"/>
<requirement
name="org.eclipse.m2e.feature.feature.group"/>
<requirement
name="org.eclipse.m2e.pde.feature.feature.group"/>
<requirement
name="de.jcup.asciidoctoreditor.feature.group"/>
<requirement
name="m2e.chromatic.feature.feature.group"/>
<requirement
name="org.sonarlint.eclipse.feature.feature.group"/>
<requirement
name="org.eclipse.m2e.core"
versionRange="2.0.0"/>
<repository
url="https://download.eclipse.org/modeling/tmf/xtext/updates/composite/marketplace/"/>
<repository
url="https://download.eclipse.org/technology/m2e/snapshots/latest/"/>
<repository
url="https://download.eclipse.org/technology/m2e/releases/latest/"/>
<repository
url="https://de-jcup.github.io/update-site-eclipse-asciidoctor-editor/update-site/"/>
<repository
url="https://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.9.0/N/LATEST/"/>
<repository
url="https://sidespin.github.io/m2e-chromatic/update/"/>
<repository
url="https://eclipse-uc.sonarlint.org"/>
</setup.p2:P2Task>
But I use a very similar setup on my private computer at home too and there the update worked flawlessly.
But should the start-order not be irrelevant in case of service handling? So this is actually a framework issue and not a "user" issue?
I cannot tell what you mean by the first sentence ... but: The type of cycle that would cause issues is something like this:
A -> B -> (optional, dynamic, reference) -> C C -> A
That's what I suspect as well.
As the ResourcePlugin is involved, I think it might be an update of some of the "core-ide" bundles and fear other users might run into the same issue as well on the next release, so if we can find a solution here (even if it will not make it into this release) I think it would be very helpful.
Yes that would be definitely important.
I think the part of the main
-thread stack-trace that helps us here most is:
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:1047)
at org.eclipse.core.resources.ResourcesPlugin$WorkspaceInitCustomizer.addingService(ResourcesPlugin.java:528)
at org.eclipse.core.resources.ResourcesPlugin$WorkspaceInitCustomizer.addingService(ResourcesPlugin.java:1)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:321)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:264)
at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:499)
I think that was the part you are referring to when mentioning the Resources-Plugin? Since I have a similar installation setup at home I will try to debug that part of the activator with it. But I don't have that much time this weekend so I don't know if I will find something soon. But I will report back as soon as possible.
I think the part of the
main
-thread stack-trace that helps us here most is:
don't think so :-)
I think that was the part you are referring to when mentioning the Resources-Plugin?
No I was referring to @tjwatson comment that due to an update some plugin might be started "later" and as the Resources-Plugin normally starts quite early, it might be because anything changed that the Resources-Plugin was updated by P2 and now starts a bit later... but that's just a guess.
But I use a very similar setup on my private computer at home too and there the update worked flawlessly.
I was just hoping one could reproduce this e.g. by upgrading a 2022-03 installation to 2022-09 ... but then we have to wait if we get this again somewhere and can capture some more context, given that a -clean
seem to solve the issue its not that dramatic anyways but maybe annoying.
I was "lucky" and encountered the same problem today after re-running the Oomph setup of my Eclipse-for-committers
version latest
and VisualVM showed identical stack-traces for the two blocked threads.
I remote-debugged it and found the following service chains (in the same order as in the stack-trace):
Thread main
:
Thread SCR Component Actor
:
Derived from the implemented services the following DS-component chains cause the dead-lock.
main:
ProjectRegistryRefreshJob -> ProjectRegistryManager -> ProjectConfigurationManager -> MavenModelManager -> MavenProjectManager
SCR Component Actor:
RepositoryRegistry -> MavenProjectManager -> ProjectConfigurationManager
So it is probably a combination of recent changes in the resources-plugin and m2e that revealed this issue. Lucky us m2e 2.0 did not made it into 2022-06 SimRel. So users might not be affected right away, unless it appears somewhere else too.
I will try to reproduce the problem in my m2e workspace with updating the target-platform. If there is anything else I should check, let me know. I did not clear the workspace yet.
The only two calls to org.apache.felix.scr.impl.ComponentRegistry.missingServicePresent()
, which causes the async call of DependencyManager.invokeBindMethodLate()
in the "SCR Component Actor" thread, that finally participates in the deadlock are for the following ServiceReference
objects:
ResourcesPlugin.start()
is called respectively its instanceLocationTracker.open()
:
{org.eclipse.m2e.core.embedder.IMaven, org.eclipse.m2e.core.embedder.IMavenConfigurationChangeListener}={service.id=163, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.internal.embedder.MavenImpl, component.id=63}
with the following dependencyManager-entries:
{org.eclipse.m2e.core.repository.IRepositoryRegistry, org.eclipse.m2e.core.project.IMavenProjectChangedListener, org.eclipse.m2e.core.embedder.ISettingsChangeListener}={service.id=422, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.internal.repository.RepositoryRegistry, component.id=77}
with the following dependencyManager-entries:
The runable executed for the second appeal is then finally stuck in the deadlock.
What's interesting is that if I update the target-platform in my m2e-workspace at the current master to use the latest 4.24-I build (i.e. https://download.eclipse.org/eclipse/updates/4.24-I-builds/I20220529-0600/
) only the first call of DependencyManager.invokeBindMethodLate()
happens and it happens in the "SCR Component Actor" Thread and the deadlock does not occur.
I think that is happening after a workspace clean and I suspect that some (m2e) bundles are started earlier with my updated Eclipse installation.
Do you know where I can find out such early/auto-start configuration?
Do you know where I can find out such early/auto-start configuration?
OK it seems to be the org.eclipse.m2e.logback.configuration
plugin which is auto-started when installed which happens before the ResourcesPlugin
is started. In a regular Eclipse Installation ResourcesPlugin.start()
is only called after the workspace selection dialog has been finished. To mimic that in a debugged Eclipse I had to put a break-point into ResourcesPlugin.start()
and wait a short time before continuing.
But even then a break-point at ServiceRegistrationImpl.getService(BundleContextImpl, ServiceConsumer):538 with condition
java.util.Arrays.toString(this.clazzes).contains(".m2e.core.project.IMavenProjectRegistry")||
java.util.Arrays.toString(this.clazzes).contains(".m2e.core.project.IProjectConfigurationManager")
only stops in the main-thread.
However I think with that knowledge it should be possible to construct a test-case (actually just what Tom suggested) where the Plug-ins are started explicitly in an order that causes the dead-lock. Maybe it can be even achieved reliably by levering some CountdownLatches
(or similar) in bind-methods/activators.
I can try to do that in the next days, unless somebody else is faster. :)
Many thanks @HannesWell for the analysis.
Do you know where I can find out such early/auto-start configuration?
Go to the run config of your product, then to "plugins", ther you can adjust the start-levels and if a plugin is auto-started or not.
If there is anything else I should check, let me know. I did not clear the workspace yet.
You probably should save the workspace and the eclipse install because I don't think the interesting things are stored in the workspace but in the configuration area of the product. Thus to reproduce it with another Eclipse-Launch you might need to point the config area to a copy of that as well (make sure not to clear it by accident!)
If there is anything else I should check, let me know. I did not clear the workspace yet.
For me it would be interesting if you can again fix this by putting a brackpoint somewhere and if this causes any issues (e.g. warnings, failing components), if not could you try to add a dump Lock
there (not a synchronized block!) that only allows a singe thread to pass that border and check if that also helps or creates a deadlock too?
But even then a break-point at ServiceRegistrationImpl.getService(BundleContextImpl, ServiceConsumer):538 with condition
I don't think that any of those are much interesting as these are "static" consumed services, you should maybe get what you expect by looking at the listener (e.g. IMavenConfigurationChangeListener
) as these are consumed dynamic, that's what I tried to describe above, that if there is a "dynamic cycle" felix emits the following message:
ENTRY org.apache.felix.scr 4 0 2022-05-30 07:29:50.029
!MESSAGE bundle org.apache.felix.scr:2.1.24.v20200924-1939 (109) Circular reference detected
trying to get service {<service interface>}={service.id=76, service.bundleid=21, service.scope=bundle, component.name=<the component involved>, component.id=10}
stack of references: <involved service references>
but can recover later from this when one of the components is activated, registered. So if you do not see this message, I thing it is just a "simple" dynamic reference here.
Derived from the implemented services the following DS-component chains cause the dead-lock.
Do you think you can list what service uses these currently hold?
Do you know where I can find out such early/auto-start configuration?
Go to the run config of your product, then to "plugins", ther you can adjust the start-levels and if a plugin is auto-started or not.
Sorry, I meant for an Eclipse installation. For launches that was clear to me.
Is there another file that controls the autostart settings in an installation than <installation-root>/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
? (I'm pretty sure that this is the file were the settings from the wizard you mentioned are written too.)
I suspect that the Equinox container storage also holds information when bundles are 'restarted' after an application has been shutdown.
If there is anything else I should check, let me know. I did not clear the workspace yet.
You probably should save the workspace and the eclipse install because I don't think the interesting things are stored in the workspace but in the configuration area of the product. Thus to reproduce it with another Eclipse-Launch you might need to point the config area to a copy of that as well (make sure not to clear it by accident!)
Done that.
If there is anything else I should check, let me know. I did not clear the workspace yet.
For me it would be interesting if you can again fix this by putting a brackpoint somewhere and if this causes any issues (e.g. warnings, failing components), if not could you try to add a dump
Lock
there (not a synchronized block!) that only allows a singe thread to pass that border and check if that also helps or creates a deadlock too?
A conditional break-point at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl:538
(in method getService(BundleContextImpl, ServiceConsumer)
), which uses the condition Thread.currentThread().getName().equals("SCR Component Actor")
, that I disabled manually just after it was hit 'resolved' the deadlock and I did not not notice any failures/warnings/errors/pop ups (but didn't test it extensively).
Since I'm remote debugging the installation I cannot simply change that, but I will try to replicate that with ordinary java-launch configuration that copies the command parameters passed by the launcher. Then that should be possible to wrap that section of the code with a single global lock.
But even then a break-point at ServiceRegistrationImpl.getService(BundleContextImpl, ServiceConsumer):538 with condition
I don't think that any of those are much interesting as these are "static" consumed services, you should maybe get what you expect by looking at the listener (e.g.
IMavenConfigurationChangeListener
) as these are consumed dynamic, that's what I tried to describe above, that if there is a "dynamic cycle" felix emits the following message:ENTRY org.apache.felix.scr 4 0 2022-05-30 07:29:50.029 !MESSAGE bundle org.apache.felix.scr:2.1.24.v20200924-1939 (109) Circular reference detected trying to get service {<service interface>}={service.id=76, service.bundleid=21, service.scope=bundle, component.name=<the component involved>, component.id=10} stack of references: <involved service references>
but can recover later from this when one of the components is activated, registered. So if you do not see this message, I thing it is just a "simple" dynamic reference here.
I added the -consoleLog
argument and got (besides others) the following print-out. So that message is present (I'm not sure why I did not yet see it when launching from the m2e workspace, but maybe that is part of the problem).
!ENTRY org.apache.felix.scr 4 0 2022-05-30 10:58:21.455
!MESSAGE bundle org.apache.felix.scr:2.1.24.v20200924-1939 (50) Circular reference detected trying to get service {org.eclipse.m2e.core.project.IProjectConfigurationManager, org.eclipse.m2e.core.project.IMavenProjectChangedListener, org.eclipse.core.resources.IResourceChangeListener}={service.id=419, service.bundleid=4650, service.scope=bundle, event.mask=4, component.name=org.eclipse.m2e.core.internal.project.ProjectConfigurationManager, component.id=68}
stack of references: ServiceReference: {org.eclipse.m2e.core.project.IProjectConfigurationManager, org.eclipse.m2e.core.project.IMavenProjectChangedListener, org.eclipse.core.resources.IResourceChangeListener}={service.id=419, service.bundleid=4650, service.scope=bundle, event.mask=4, component.name=org.eclipse.m2e.core.internal.project.ProjectConfigurationManager, component.id=68}
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.project.registry.MavenProjectManager (72)] reference [MavenProjectChangedListener]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.project.registry.MavenProjectManager (72)] reference [MavenProjectChangedListener]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager (74)] reference [MavenProjectChangedListener]
ServiceReference: {org.eclipse.m2e.core.embedder.MavenModelManager}={service.id=418, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.embedder.MavenModelManager, component.id=62}
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.project.ProjectConfigurationManager (68)] reference [mavenModelManager]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.project.ProjectConfigurationManager (68)] reference [mavenModelManager]
ServiceReference: {org.eclipse.m2e.core.project.IMavenProjectRegistry}={service.id=417, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.internal.project.registry.MavenProjectManager, component.id=72}
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.repository.RepositoryRegistry (77)] reference [projectManager]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.embedder.MavenModelManager (62)] reference [projectManager]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.embedder.MavenModelManager (62)] reference [projectManager]
Dependency: DependencyManager: Component [Component: org.eclipse.m2e.core.internal.repository.RepositoryRegistry (77)] reference [projectManager]
!STACK 0
java.lang.Exception: stack trace
at org.apache.felix.scr.impl.ComponentRegistry.enterCreate(ComponentRegistry.java:493)
at org.apache.felix.scr.impl.BundleComponentActivator.enterCreate(BundleComponentActivator.java:717)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:899)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:220)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:217)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:118)
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:48)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:547)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:534)
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:660)
at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88)
at org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:675)
at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2545)
at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.prebind(DependencyManager.java:431)
at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1822)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1057)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:953)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:918)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:220)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:217)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:118)
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:48)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:547)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:534)
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:660)
at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88)
at org.apache.felix.scr.impl.inject.field.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:525)
at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2545)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1392)
at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1822)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1057)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:953)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:918)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:220)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:217)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:118)
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:48)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:547)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:534)
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:660)
at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88)
at org.apache.felix.scr.impl.inject.field.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:525)
at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2545)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1392)
at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1822)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1057)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:953)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:918)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:220)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:217)
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:118)
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:48)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:547)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:534)
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:660)
at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88)
at org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:675)
at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2545)
at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.prebind(DependencyManager.java:431)
at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1822)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1057)
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:953)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:785)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1271)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1222)
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1200)
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1121)
at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:928)
at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:864)
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1152)
at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:114)
at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:123)
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:961)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:937)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:874)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:141)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:262)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:500)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:519)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:1047)
at org.eclipse.core.resources.ResourcesPlugin$WorkspaceInitCustomizer.addingService(ResourcesPlugin.java:528)
at org.eclipse.core.resources.ResourcesPlugin$WorkspaceInitCustomizer.addingService(ResourcesPlugin.java:1)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:321)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:264)
at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:499)
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:818)
at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:810)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:767)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1032)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371)
at org.eclipse.osgi.container.Module.doStart(Module.java:605)
at org.eclipse.osgi.container.Module.start(Module.java:468)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:513)
at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:570)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:335)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:397)
at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:41)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:496)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:416)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:168)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:153)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
10:58:21.516 [main] DEBUG org.eclipse.m2e.core.internal.project.registry.ProjectRegistryRefreshJob - Queued refresh request: [/Dash License Tool Core/pom.xml, /Dash License Tool Maven Plugin/pom.xml, /Dash License Tool Root/pom.xml, /m2e-core/pom.xml, /m2e-core-tests/pom.xml, /m2e-maven-runtime/pom.xml, /orbit-recipes/pom.xml, /org.eclipse.m2e.apt.core/pom.xml, /org.eclipse.m2e.apt.tests/pom.xml, /org.eclipse.m2e.apt.ui/pom.xml, /org.eclipse.m2e.archetype.common/pom.xml, /org.eclipse.m2e.binaryproject/pom.xml, /org.eclipse.m2e.binaryproject.tests/pom.xml, /org.eclipse.m2e.binaryproject.ui/pom.xml, /org.eclipse.m2e.core/pom.xml, /org.eclipse.m2e.core.tests/pom.xml, /org.eclipse.m2e.core.ui/pom.xml, /org.eclipse.m2e.core.ui.tests/pom.xml, /org.eclipse.m2e.discovery/pom.xml, /org.eclipse.m2e.editor/pom.xml, /org.eclipse.m2e.editor.lemminx/pom.xml, /org.eclipse.m2e.editor.lemminx.tests/pom.xml, /org.eclipse.m2e.editor.tests/pom.xml, /org.eclipse.m2e.editor.tests-2/pom.xml, /org.eclipse.m2e.feature/pom.xml, /org.eclipse.m2e.jdt/pom.xml, /org.eclipse.m2e.jdt.tests/pom.xml, /org.eclipse.m2e.jdt.ui/pom.xml, /org.eclipse.m2e.launching/pom.xml, /org.eclipse.m2e.lemminx.feature/pom.xml, /org.eclipse.m2e.lifecyclemapping.defaults/pom.xml, /org.eclipse.m2e.logback.appender/pom.xml, /org.eclipse.m2e.logback.configuration/pom.xml, /org.eclipse.m2e.logback.feature/pom.xml, /org.eclipse.m2e.maven.runtime/pom.xml, /org.eclipse.m2e.maven.runtime.slf4j.simple/pom.xml, /org.eclipse.m2e.model.edit/pom.xml, /org.eclipse.m2e.pde.connector/pom.xml, /org.eclipse.m2e.pde.feature/pom.xml, /org.eclipse.m2e.pde.target/pom.xml, /org.eclipse.m2e.pde.ui/pom.xml, /org.eclipse.m2e.profiles.core/pom.xml, /org.eclipse.m2e.profiles.core.tests/pom.xml, /org.eclipse.m2e.profiles.ui/pom.xml, /org.eclipse.m2e.refactoring/pom.xml, /org.eclipse.m2e.repository/pom.xml, /org.eclipse.m2e.scm/pom.xml, /org.eclipse.m2e.sdk.feature/pom.xml, /org.eclipse.m2e.sourcelookup/pom.xml, /org.eclipse.m2e.sourcelookup.ui/pom.xml, /org.eclipse.m2e.tests/pom.xml, /org.eclipse.m2e.tests.common/pom.xml, /org.eclipse.simrel.build/pom.xml, /target-platform/pom.xml, /test.OSGI.ee/pom.xml]
org.eclipse.m2e.logback.configuration: Logback config file: C:\dev\workspaces\eclipse.m2e\.metadata\.plugins\org.eclipse.m2e.logback.configuration\logback.1.17.0.20220517-1739.xml
org.eclipse.m2e.logback.configuration: Initializing logback
Derived from the implemented services the following DS-component chains cause the dead-lock.
Do you think you can list what service uses these currently hold?
Do you mean the users of the services that are blocking each other?
Is there another file that controls the autostart settings in an installation than
<installation-root>/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
As always it depends ;-)
bundles.info
if used by the simpleconfigurator, but there is also configuration in the configuration/config.ini
I suspect that the Equinox container storage also holds information when bundles are 'restarted' after an application has been shutdown.
You can dynamically change the start level but don't know if P2 do this.
Do you mean the users of the services that are blocking each other?
The lock-objects in your initial trace says:
"main": waiting to lock monitor 0x00007fad34006700 (object 0x0000000092005488, a org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse), which is held by "SCR Component Actor" "SCR Component Actor": waiting to lock monitor 0x00007fad34008e00 (object 0x000000009260e008, a org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse), which is held by "main"
So the interesting question is what are those ServiceFactoryUse objects and why we get in the undesirable state that one thread locks it while another require it (and how we can prevent this).
Since I'm remote debugging the installation I cannot simply change that
It is a bit cumbersome to setup, and I have not tested it but actually the following should work:
configuration
and workspace
folder just in case you need to restore that laterMain > Location
to the workspace folderConfiguration > Configuration
to the configuration
folderConfiguration > config.ini > use an exiting config.ini
This then should allow to launch that product from within eclipse as if you launched it from commandline and debug it, if that works, you should be able to import individual plugins (e.g. m2e) of interest into the workspace to change/debug code with them, just make sure it is the version installed in the eclipse you are using so you don't get errors because of changed API.
After detailed debugging/manual tracing to the start up of my dead-locking Eclipse I was able to create a protocol of the events that lead to that situation. With that I was able to create a test case that reproduces that situation reliably:
TLDR;
It is caused by multiple (larger) circles of optional references (i.e. cardinality=multiplebe
and policy = DYNAMIC
) dependencies in the same bundle. Those optional references of the cycle are lazy bound in the SCR Component Actor
Thread, that starts at a different point in the cycle.
So the interesting question is what are those ServiceFactoryUse objects and why we get in the undesirable state that one thread locks it while another require it (and how we can prevent this).
Those ServiceFactoryUse
are obtained in ServiceRegistrationImpl.getService()
from the user BundleContext
's servicesInUseMap
, that uses the ServiceRegistration
as key. So for the same bundle and same ServiceReference
the same ServiceUse
is used.
The reference locking cycle is the following:
Thread "main":
ProjectRegistryRefreshJob
--[ProjectRegistryManager manager]-->
ProjectRegistryManager
--[addMavenProjectChangedListener()]-->
ProjectConfigurationManager
--[IMaven maven]-->
MavenImpl
-- [List<ISettingsChangeListener> settingsListeners, cardinality = MULTIPLE, policy = DYNAMIC]-->
RepositoryRegistry (not satisfied)
--[MavenModelManager mavenModelManager]-->
MavenModelManager
--[IMavenProjectRegistry projectManager]-->
MavenProjectManager
Thread "SCR Component Actor":
RepositoryRegistry
--[IMaven maven]-->
MavenImpl (already created in main-thread)
--[IMavenProjectRegistry projectManager]-->
MavenProjectManager
--[addMavenProjectChangedListener(), cardinality = MULTIPLE, policy = DYNAMIC]-->
ProjectConfigurationManager
The problem is that the optional reference from MavenImpl
to RepositoryRegistry
is not satisfied initially because the latter also references (not optional) the former. That reference is satisfied as soon as MavenImpl
is activated, which triggers the activation of RepositoryRegistry
in the SCR thread. But RepositoryRegistry
directly references MavenProjectManager
, which optionally references ProjectConfigurationManager
and is therefore attempted to be active. At the same time ProjectConfigurationManager
is under ongoing activation in the main thread and after it starts to activate MavenModelManager
the main thread also tries to activate MavenProjectManager
that the SCR is activating too.
The protocol of events that lead to this situation:
ResourceChangeListenerRegistrar is activated because its IWorkspace reference is satisfies.
Subsequently its multi reference to IResourceChangeListener is collected
Thread "main":
Activation attempt: ProjectRegistryRefreshJob -> dependencies are collected
collect reference "ProjectRegistryManager manager":
Activation attempt: ProjectRegistryManager
collect reference "addMavenProjectChangedListener()":
Activation attempt: ProjectConfigurationManager
collect reference "IMaven maven":
Activation attempt: MavenImpl
collect reference "IMavenConfiguration mavenConfiguration":
Activation attempt: MavenConfigurationImpl
dependencies/references are all collected successfully (for multi-ref "addConfigurationChangeListener()" nothing is found because IMaven is not yet completly activated, but it is nevertheless satisfied)
component is successfully activated
collect reference "List<ISettingsChangeListener> settingsListeners" (0..n):
Activation attempt: RepositoryRegistry
ACTIVATION FAILED because reference "IMaven maven" is not yet statisfied
=> m_componentManager.registerMissingDependency is called for that referemce
component is successfully activated
=> org.apache.felix.scr.impl.ComponentRegistry.missingServicePresent() is called
for ServiceReference: "{org.eclipse.m2e.core.embedder.IMaven, org.eclipse.m2e.core.embedder.IMavenConfigurationChangeListener}={service.id=163, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.internal.embedder.MavenImpl, component.id=63}"
and felix.scr.DependencyManagers:
"DependencyManager: Component [Component: org.eclipse.m2e.core.internal.preferences.MavenConfigurationImpl (67)] reference [ConfigurationChangeListener]"
"DependencyManager: Component [Component: org.eclipse.m2e.core.internal.repository.RepositoryRegistry (77)] reference [maven]"
=> From now on the "SCR Component Actor" thread starts to work in parallel
collect reference "IMavenConfiguration mavenConfiguration":
already activated MavenConfigurationImpl is bound
collect reference "IMavenMarkerManager mavenMarkerManager"
Activation attempt: MavenMarkerManager
collect reference "IMavenConfiguration mavenConfiguration":
already activated MavenConfigurationImpl is bound
component is successfully activated
collect reference "MavenModelManager mavenModelManager"
Activation attempt: MavenModelManager
collect reference "IMaven maven":
already activated MavenImpl is bound
collect reference "IMavenProjectRegistry projectManager":
Activation attempt: MavenProjectManager
##### blocks ##### in ServiceRegistrationImpl.getService() because "use" is already locked by thread "SCR Component Actor" while activating MavenProjectManager
Thread "SCR Component Actor"
calls DependencyManager.invokeBindMethodLate() for ServiceReference and component sheduled in the main thread after MavenImpl has been acticated.
=> for DependencyManager[MavenConfigurationImpl] MavenImpl is bound to MavenConfigurationImpl via "addConfigurationChangeListener()"
=> for DependencyManager[RepositoryRegistry]
calls org.apache.felix.scr.impl.ComponentRegistry.missingServicePresent()
with ServiceReference: "{org.eclipse.m2e.core.repository.IRepositoryRegistry, org.eclipse.m2e.core.project.IMavenProjectChangedListener, org.eclipse.m2e.core.embedder.ISettingsChangeListener}={service.id=422, service.bundleid=4650, service.scope=bundle, component.name=org.eclipse.m2e.core.internal.repository.RepositoryRegistry, component.id=77}"
and felix.scr.DependencyManagers:
"DependencyManager: Component [Component: org.eclipse.m2e.core.internal.embedder.MavenImpl (63)] reference [settingsListeners]@2"
=> calls "m_componentManager.notifyWaiters()" in DependencyManager
=> calls DependencyManager.invokeBindMethodLate() for ServiceReference of MavenImpl mentioned above that was just scheduled in the same thread as prvious task. and component sheduled in the main thread after MavenImpl has been acticated.
=> Attempts to bind RepositoryRegistry to MavenImpl via "addConfigurationChangeListener()"
Activation attempt: RepositoryRegistry
collect reference "IMaven maven":
already activated MavenImpl is bound
collect reference "IMavenProjectRegistry projectManager":
Activation attempt: MavenProjectManager
collect reference "addMavenProjectChangedListener()" (0..n):
Activation attempt: ProjectConfigurationManager
##### blocks ##### in ServiceRegistrationImpl.getService() because "use" is already locked by thread "main" while activating ProjectConfigurationManager
After updating one of my Eclipse installations (Eclipse Modlling-tools provided by Oomph plus some more plugins) on Linux, it seemed not to start anymore (no UI showed up, not even the icon becomes visible in the task-bar). Attempting to start it a second time did not work because the workspace is blocked. Nevertheless the System Monitor showed that the eclipse process is running and VisualVM detected the following deadlock: