How to diagnose an Invalid thread access SWTException?

Question

We're customizing an Eclipse RCP based tool for a client. They have trouble loading it on one of their computers (it works on others) and have provided the following error log.

!SESSION 2009-01-23 12:09:05.593 ----------------------------------------------- eclipse.buildId=unknown java.version=1.5.0_12 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86

!ENTRY org.eclipse.osgi 4 0 2009-01-23 12:09:07.500 !MESSAGE Bundle com.yantra.yfc.rcp.desktop.ri not found.

!ENTRY org.eclipse.osgi 4 0 2009-01-23 12:09:11.906 !MESSAGE Application error !STACK 1 org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:3374) at org.eclipse.swt.SWT.error(SWT.java:3297) at org.eclipse.swt.SWT.error(SWT.java:3268) at org.eclipse.swt.widgets.Display.error(Display.java:978) at org.eclipse.swt.widgets.Display.checkDevice(Display.java:638) at org.eclipse.swt.graphics.Device.dispose(Device.java:261) at com.yantra.yfc.rcp.YRCApplication.run(YRCApplication.java:176) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)

I have googled the exception but this seems to happen mostly when people try to develop applications using different threads. Since we don't see this problem on any other computer I'm at a loss as to what might be causing it.

It must be a configuration problem on the machine in question, as the code is from the vendor (so presumably well tested) and works on every other machine we've tested it on.

Does anyone have any suggestions about what might be behind the problem for that computer? Or suggestions about lines of investigation which might reveal the issue?

Answer 1

There's only one UI thread in Eclipse. In a nutshell, the rules are:

• If you got called as part of a UI operation (e.g. event handler, view initialization) you are in the UI thread.
• All other operations that invoke a UI (e.g. a job which needs to show a dialog or send information to a view which modifies a widget) - need to sync with the UI thread.

This is basically done like this:

 Display.getDefault().syncExec( new Runnable() {  public void run() { } });

Your code goes in the run method. You may also use the asyncExec method to continue without waiting for the UI to finish.

Try using the snippet above to wrap the problematic code.

EDIT: Ending bracket for Runnable() was missing in the snippet . After adding snippet works fine.

Answer 2

It seems to me that an Exception is thrown in the application thread, that happens only in some machines. Probably there is code in the RCP application to display the exception on the GUI with some dialog box, but this is done in the wrong thread. That would explain why it happens only on some machines. It would also explain why the problem went undetected.... it probably never happens in the dev's computers so they never bothered to check that the UI Access is done using the right thread. I had a similar problem once.

My suggestion would be to take a close look to:

com.yantra.yfc.rcp.YRCApplication.run(YRCApplication.java:176)

As the code is compiled with line numbers, you can attach a debugger to this line even if you have no source code, and try to see what happens. I am pretty sure that when you hit this breakpoint on the problematic machine, an Exception will be thrown. That will be your "Real" exception.