Bug 485 - Freeze on loadLibrary of AWT in Eclipse RCP app inside GLProfile.initSingleton() on Mac OS X
Summary: Freeze on loadLibrary of AWT in Eclipse RCP app inside GLProfile.initSingleto...
Status: VERIFIED INVALID
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: pc_x86_64 macosx
: --- normal
Assignee: Wade Walker
URL:
Depends on:
Blocks:
 
Reported: 2011-03-24 02:57 CET by Wade Walker
Modified: 2011-04-03 22:07 CEST (History)
0 users

See Also:
Type: ---
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wade Walker 2011-03-24 02:57:29 CET
The loadLibrary of AWT inside GLProfile.initSingleton() freezes on Mac OS X 10.6.7, nvidia GeForce 320M, Java 1.6.0_24. It works fine in a standalone SWT app, but freezes in an Eclipse RCP app.

I can force it not to load AWT by setting -Djava.awt.headless=true, but I'm not sure the app will work that way -- still debugging later problems.

Here's the stack trace:

Daemon Thread [Thread-1] (Suspended)	
	ClassLoader$NativeLibrary.load(String) line: not available [native method]	
	ClassLoader.loadLibrary0(Class, File) line: 1823	
	ClassLoader.loadLibrary(Class, String, boolean) line: 1720	
	Runtime.loadLibrary0(Class, String) line: 823	
	System.loadLibrary(String) line: 1045	
	LoadLibraryAction.run() line: 50	
	AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]	
	Toolkit.loadLibraries() line: 1605	
	Toolkit.<clinit>() line: 1627	
	JAWTJNILibLoader$1.run() line: 58	
	AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]	
	JAWTJNILibLoader.loadAWTImpl() line: 53	
	JAWTUtil.<clinit>() line: 66	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	ReflectionUtil.callMethod(Object, Method, Object[]) line: 267	
	NativeWindowFactory.initSingleton(boolean) line: 176	
	GLProfile.initProfilesForDefaultDevices(boolean) line: 1095	
	GLProfile.access$000(boolean) line: 66	
	GLProfile$1.run() line: 107	
	AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]	
	GLProfile.initSingleton(boolean) line: 105	
	Activator.<clinit>() line: 67	
	NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method]	
	NativeConstructorAccessorImpl.newInstance(Object[]) line: 39	
	DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27	
	Constructor<T>.newInstance(Object...) line: 513	
	Class<T>.newInstance0() line: 355	
	Class<T>.newInstance() line: 308	
	BundleHost(AbstractBundle).loadBundleActivator() line: 151	
	BundleContextImpl.start() line: 751	
	BundleHost.startWorker(int) line: 370	
	BundleHost(AbstractBundle).start(int) line: 284	
	SecureAction.start(Bundle, int) line: 417	
	BundleLoader.setLazyTrigger() line: 265	
	EclipseLazyStarter.postFindLocalClass(String, Class, ClasspathManager) line: 106	
	ClasspathManager.findLocalClass(String) line: 453	
	DefaultClassLoader.findLocalClass(String) line: 216	
	BundleLoader.findLocalClass(String) line: 393	
	BundleLoader.findClassInternal(String, boolean, ClassLoader) line: 469	
	BundleLoader.findClass(String, boolean) line: 422	
	BundleLoader.findClass(String) line: 410	
	DefaultClassLoader.loadClass(String, boolean) line: 107	
	DefaultClassLoader(ClassLoader).loadClass(String) line: 248	
	BundleLoader.loadClass(String) line: 338	
	BundleHost.loadClass(String, boolean) line: 232	
	BundleHost(AbstractBundle).loadClass(String) line: 1197	
	EquinoxRegistryStrategy(RegistryStrategyOSGI).createExecutableExtension(RegistryContributor, String, String) line: 174	
	ExtensionRegistry.createExecutableExtension(RegistryContributor, String, String) line: 904	
	ConfigurationElement.createExecutableExtension(String) line: 243	
	ConfigurationElementHandle.createExecutableExtension(String) line: 55	
	EclipseAppHandle.run(Object) line: 191	
	EclipseAppLauncher.runApplication(Object) line: 110	
	EclipseAppLauncher.start(Object) line: 79	
	EclipseStarter.run(Object) line: 369	
	EclipseStarter.run(String[], Runnable) line: 179	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	Main.invokeFramework(String[], URL[]) line: 620	
	Main.basicRun(String[]) line: 575	
	Main.run(String[]) line: 1408	
	Main.main(String[]) line: 1384
Comment 1 Wade Walker 2011-03-24 03:07:16 CET
The bug 486 shows up after I bypass this one. Not sure if the lack of AWT load causes bug 486 (it also happens if I omit GLProfile.initSingleton() instead of using -Djava.awt.headless).
Comment 2 Wade Walker 2011-03-25 03:04:03 CET
This bug has been seen in the wild at http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/#comment-52. He mentions the same behavior I've seen, where Eclipse sticks at the flash screen.

The problem seems to be when loading the AWT library -- it freezes inside the loadLibrary() call.
Comment 3 Wade Walker 2011-04-02 23:58:17 CEST
Setting -Djava.awt.headless=true fixes this problem, and also fixes a separate problem where standalone (non-RCP) SWT apps freeze when you quit (on Mac OS X). Apparently loading libawt.jnilib if you're using SWT on the Mac is just a bad idea.

The thread at http://lists.apple.com/archives/Java-dev/2008/Dec/msg00249.html says that Apple's JDK checks for -XstartOnFirstThread=true and if so doesn't load AWT. Perhaps we should check for this in NativeWindowFactory.initSingleton()? Or maybe run all SWT apps with -Djava.awt.headless=true on the Mac?
Comment 4 Wade Walker 2011-04-03 22:07:14 CEST
Apparently the right answer is to set -Djava.awt.headless=true on Mac OS X RCP projects. The RuntimeMXBean can't see the -XstartOnFirstThread argument to the JVM, so we can't piggyback on that. And there's no way for GLProfile.initSingleton() to know that a program is going to use SWT later, so I don't think we can change JOGL to fix this.