Bug 448 - etc/test.sh hangs on CentOS 5.4 for all builds after b187
Summary: etc/test.sh hangs on CentOS 5.4 for all builds after b187
Status: VERIFIED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2
Hardware: pc_x86_64 linux
: --- major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2010-12-21 17:20 CET by Wade Walker
Modified: 2010-12-29 17:32 CET (History)
0 users

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


Attachments
Output of etc/test.sh on CentOS 5.4 (clean build of commit 2cbab63bd6c230d31b8ae6f1d794ad49bf23bb53) (58.67 KB, application/octet-stream)
2010-12-21 17:24 CET, Wade Walker
Details
centos-5.5-x64-nvidia test.log no debug (9.44 KB, text/plain)
2010-12-22 00:47 CET, Sven Gothel
Details
centos-5.5-x64-nvidia test.log debug (93.63 KB, text/plain)
2010-12-22 00:48 CET, Sven Gothel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wade Walker 2010-12-21 17:20:53 CET
After b187, all versions of JOGL 2 hang on 64-bit CentOS 5.4 when running etc/test.sh (or any other test).

I've tested many versions from after b187 up to today, and they all act the same way after the new boolean argument was added to GLProfile.initSingleton(). I performed this test by checking out the latest code, building it, and running etc/test.sh from inside the build directory.

The hang seems to happen inside GLProfile.initSingleton() at the native method dispatch_glXMakeCurrent1() inside glXMakeCurrent(). Here's the stack trace where I suspended it before trying to step across the hanging line:

Thread [main] (Suspended (breakpoint at line 949 in GLX))	
	GLX.glXMakeCurrent(long, long, long) line: 949	
	X11OnscreenGLXContext(X11GLXContext).glXMakeContextCurrent(long, long, long, long) line: 149	
	X11OnscreenGLXContext(X11GLXContext).makeCurrentImpl(boolean) line: 407	
	X11OnscreenGLXContext(GLContextImpl).makeCurrentLocking() line: 418	
	X11OnscreenGLXContext(GLContextImpl).makeCurrent() line: 351	
	GLProfile.dumpGLInfo(GLDrawableFactoryImpl, AbstractGraphicsDevice) line: 1315	
	GLProfile.initProfilesForDeviceImpl(AbstractGraphicsDevice) line: 1303	
	GLProfile.initProfilesForDevice(AbstractGraphicsDevice) line: 1224	
	GLProfile.initProfilesForDefaultDevices(boolean) line: 1192	
	GLProfile.access$000(boolean) line: 66	
	GLProfile$1.run() line: 112	
	AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]	
	GLProfile.initSingleton(boolean) line: 110	
	TestGearsAWT.initClass() line: 54	
	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	
	FrameworkMethod$1.runReflectiveCall() line: 44	
	FrameworkMethod$1(ReflectiveCallable).run() line: 15	
	FrameworkMethod.invokeExplosively(Object, Object...) line: 41	
	RunBefores.evaluate() line: 27	
	RunAfters.evaluate() line: 31	
	BlockJUnit4ClassRunner(ParentRunner<T>).run(RunNotifier) line: 236	
	Suite.runChild(Runner, RunNotifier) line: 128	
	Suite.runChild(Object, RunNotifier) line: 24	
	ParentRunner$3.run() line: 193	
	ParentRunner$1.schedule(Runnable) line: 52	
	Suite(ParentRunner<T>).runChildren(RunNotifier) line: 191	
	ParentRunner<T>.access$000(ParentRunner, RunNotifier) line: 42	
	ParentRunner$2.evaluate() line: 184	
	Suite(ParentRunner<T>).run(RunNotifier) line: 236	
	JUnitCore.run(Runner) line: 157	
	JUnitCore.run(Request) line: 136	
	JUnitCore.run(Class<?>...) line: 117	
	JUnitCore.runMain(JUnitSystem, String...) line: 98	
	JUnitCore.runMainAndExit(JUnitSystem, String...) line: 53	
	JUnitCore.main(String...) line: 45	
	TestGearsAWT.main(String[]) line: 120	

Once it's hung, the SharedResourceRunner thread is the only one that will pause:

Daemon Thread [main-SharedResourceRunner] (Suspended)	
	Object.wait(long) line: not available [native method]	
	SharedResourceRunner(Object).wait() line: 485	
	SharedResourceRunner.run() line: 193	
	Thread.run() line: 619	

The Java thread has to be terminated with "kill -9"; Eclipse's debugger can't kill it normally.

I'll attach the log file to this bug.
Comment 1 Wade Walker 2010-12-21 17:24:12 CET
Created attachment 204 [details]
Output of etc/test.sh on CentOS 5.4 (clean build of commit 2cbab63bd6c230d31b8ae6f1d794ad49bf23bb53)
Comment 2 Sven Gothel 2010-12-22 00:47:42 CET
Created attachment 205 [details]
centos-5.5-x64-nvidia test.log no debug
Comment 3 Sven Gothel 2010-12-22 00:48:08 CET
Created attachment 206 [details]
centos-5.5-x64-nvidia test.log debug
Comment 4 Sven Gothel 2010-12-22 00:51:01 CET
see attachment #205 [details] and attachment #206 [details]
which ran with the latest build 
  2.0-b264-20101221
  master
  2cbab63bd6c230d31b8ae6f1d794ad49bf23bb53

it's CentOS 5.5
  2.6.18-194.26.1.el5
  GeForce 8400 GS
  gdm/gnome
Comment 5 Wade Walker 2010-12-22 18:26:00 CET
OK, I'll try updating my drivers, and also I'll try running with a single monitor instead of two monitors -- maybe one of those is the problem.
Comment 6 Wade Walker 2010-12-29 17:32:30 CET
Sorry, this was a driver bug. The machine was at driver version 190.42 (I thought our sysadmins had updated it, but I should have checked more carefully). At driver version 260.19.20, etc/test.sh passes.

However, some AWT tests hang at close on this configuration. I'll enter a new bug for those.