Community
Participate
Working Groups
This is a placeholder for a problem we've talked about in email. I have a method invoking Display.syncExec() to execute a Runnable. Problem is, it appears that the Display never wakes up to execute the Runnable. Other syncExec() calls before this one run cleanly, so I'm not sure why it gets stuck on this one, but I step through to where the synchronizer adds the runnable to its messages and tells the display to wake up using an OS call. The display thread continues sleeping, however. In a problem you noticed, a thread would not wake up to read if an image was successfully loaded.
Has there been any activity on this? Some of my coworkers detected what appears to be a similar problem, running WSDD 4.0 on Linux. I'd personally like to see this fixed as it is stopping me from running our JUnit test suite on Linux Motif.
SSQ will be back in a day or two. He was actively looking at this but did not determine the problem.
For some reason in some circumtances Xt only listens for X events ignoring other alternate inputs which are used by our wake up mechanism. When that happens the display thread waits forever. This Xt bug has been worked around.
Is there a fix for this that we can try in Eclipse 1.0?
The final fix is really complicated and involves many changes. I don't think it can be back ported to R1.0. The method below fixes the problem too, but it is not the final solution which is released in R2.0. You can try this. If it fixes your problem, you need to go through the normal procedures of getting a patch to R1.0. +++++++++++++++++++++++ From org.eclipse.swt.widgets.Display: public boolean sleep () { checkDevice (); int xtContext = OS.XtDisplayToApplicationContext (xDisplay); /* * Bug in Xt. Under certain circumstances Xt waits * forever looking for X events, ignoring alternate * inputs. The fix is to never sleep forever. */ int sleepID = OS.XtAppAddTimeOut (xtContext, 100, 0, 0); boolean result = OS.XtAppPeekEvent (xtContext, xEvent); if (sleepID != 0) OS.XtRemoveTimeOut (sleepID); return result; } ++++++++++++++++++++++++++
Could I please get a version of this patch to try in the form of the swt.jar for org.eclipse.swt for Eclipse 1.0 for Linux?
Created attachment 310 [details] R1.0 JAR containing the fix (original name swt.jar)
I donwloaded the attached swt.jar and it seems very different from the Eclipse 1.0 jar: attached jar: 364 files, 1,793 kb Eclipse 1.0 swt jar: 458 files, 1,056 kb
Actually, the Eclipse 1.0 jar was 1506kb, not 1056. The SWT version number was 1137. Since the file swtsrc.jar is included in Eclipse 1.0, I'd assume one could just modify that one method there and recompile the contents.
Yes, I could load this and recompile, but I would really like to test on the true candidate jar, not one that I created
I downloaded "eclipse-SDK-R1.0-linux-motif.zip" from www.eclipse.org and the swt.jar in the zip has 364 files. Are you comparing the new jar with the jar for Windows instead of Linux/Motif?
D'oh! Sorry about that. I made that mistake, I don't know about Tim.
You are correct, I looked at the wrong one
I have been running with the jar Tim created, and while less frequent, the workbench is still crashing on Linux.I am attaching the latest dump I received in the console (stefCrash.txt).
Created attachment 328 [details] dump written to console
The problem Stef is seeing is not the same problem as to one described by this PR which is hang/deadlock, not a GPF. The GPF problem has been fixed a while ago and requires a change in our C code. I could not find the PR associated with it though. Anyway, I will attach a new SWT shared library so that you can try out. Which change are you interested? I mean which change should be in the patch?
Created attachment 329 [details] SWT shared library (original name "libswt-linux-1137.so")
