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

Bug 364048

Summary:

Possible deadlock in ServiceRegistry (patch included)

Product:

[Eclipse Project] Equinox

Reporter:

Michel Krämer <michel.kraemer>

Component:

Framework

Assignee:

equinox.framework-inbox <equinox.framework-inbox>

Status:

RESOLVED WORKSFORME

QA Contact:

Severity:

normal

Priority:

CC:

michel.kraemer, tjwatson

Version:

3.7.1

Target Milestone:

---

Hardware:

OS:

Windows 7

See Also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=359535

Whiteboard:

Attachments:

Description	Flags
Stacktrace for the deadlock	none
Proposed patch to fix the deadlock	none

Description Michel Krämer

2011-11-17 10:37:50 EST

Build Identifier: R37x_v20110808-1106

We are experiencing the same issue as described in #359535, but our stacktrace is quite different (see attached file). There is a deadlock in ServiceRegistry.getNextServiceId() which is unnecessarily locking the whole class.

We were able to resolve this issue by introducing a separate lock for the "serviceid" member variable. Our patch is attached below.

Reproducible: Sometimes

Steps to Reproduce:
1. Start framework
2. Publish some services from several threads at the same time

Comment 1 Michel Krämer

2011-11-17 10:38:28 EST

Created attachment 207150 [details]
Stacktrace for the deadlock

Comment 2 Michel Krämer

2011-11-17 10:39:40 EST

Created attachment 207151 [details]
Proposed patch to fix the deadlock

Comment 3 Thomas Watson

2011-11-17 10:49:58 EST

Are you using osgi.classloader.singleThreadLoads=true option?  If so please try without that option.  That is a rather dangerous option on modern VMs and I have removed it from the Juno builds.

Comment 4 Michel Krämer

2011-11-17 10:51:32 EST

We know this option and we already removed it.

Comment 5 BJ Hargrave

2011-11-17 14:59:08 EST

There seems to be some other thing at work here (like the single threaded loads option). Also the stacktrace does not reveal who owns DefaultClassLoader  (id=73)? So it does not show the closure of the embrace.

Comment 6 Michel Krämer

2011-11-18 03:11:12 EST

Yes, you're right. The stacktrace does not show who owns DefaultClassLoader (id=73). Bummer. I can't reproduce it anymore now, but the patch definitely solved the problem yesterday.

SpringOsgiExtenderThread-4 waits for ServiceRegistry (id=76) which is owned by SpringOsgiExtenderThread-5 which itself waits for DefaultClassLoader (id=73) which is locked for some unknown reason. SpringOsgiExtenderThread-4 only has to wait because ServiceRegistry.getNextServiceId() locks the whole class. However, this is not necessary, because it just increments a single member variable which is not used in any other method anyhow.

This bug is also related to #359535. We are also using Spring OSGi to publish most of our services.

Comment 7 Thomas Watson

2012-01-06 14:56:04 EST

(In reply to comment #4)
> We know this option and we already removed it.

I want to reconfirm that you were not using that option when you produced the following stacktrace:

Thread [SpringOsgiExtenderThread-1] (Suspended)	
	waiting for: DefaultClassLoader  (id=86)	
	Object.wait(long) line: not available [native method]	
	DefaultClassLoader(Object).wait() line: 485	
	BundleLoader.lock(Object) line: 1284 <<< RED FLAG!! should NOT be called
	BundleLoader.findClass(String, boolean) line: 428	
	BundleLoader.findClass(String) line: 417	
	DefaultClassLoader.loadClass(String, boolean) line: 107	
	DefaultClassLoader(ClassLoader).loadClass(String) line: not available	
	DependencyServiceManager.register() line: 364	
	DependencyWaiterApplicationContextExecutor.stageOne() line: 270	
	DependencyWaiterApplicationContextExecutor.refresh() line: 178	
	OsgiBundleXmlApplicationContext(AbstractDelegatedExecutionApplicationContext).refresh() line: 159	
	LifecycleManager$1.run() line: 223	
	Thread.run() line: not available


The following call should never happen unless osgi.classloader.singleThreadLoads=true

BundleLoader.lock(Object) line: 1284 <<< RED FLAG!! should NOT be called

Without this option, you can no longer reproduce this deadlock.  I would like to close as works for me.  Please reopen if you find another case of deadlock and we can confirm that the option osgi.classloader.singleThreadLoads=true is not being used.  Thanks.