Community
Participate
Working Groups
Could you SWT team please investigate why their tests are timing out on linux gtk x86 platform. They are delaying test results by over an hour for the past few builds. From build N20110327-2000. java-test: [echo] Running org.eclipse.swt.tests.junit.AllGtkTests. Result file: /buildtest/N20110327-2000/eclipse-testing/results/linux.gtk.x86_6.0/org.eclipse.swt.tests.junit.AllGtkTests.xml. [java] [java] (My Application Name:27022): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 0 [java] [java] (My Application Name:27022): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 0 [java] [java] (My Application Name:27022): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 0 [java] [java] (My Application Name:27022): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 0 [java] [java] (My Application Name:27022): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 0 [java] Timeout: killed the sub-process [java] Java Result: -1 collect-results: [junitreport] the file /buildtest/N20110327-2000/eclipse-testing/test-eclipse/eclipse/org.eclipse.swt.tests.junit.AllGtkTests.xml is empty. [junitreport] This can be caused by the test JVM exiting unexpectedly [xslt] Transforming into /buildtest/N20110327-2000/eclipse-testing/results/linux.gtk.x86_6.0
My Linux just died this morning, can you guys see what is happening here ?
This problem is caused by changes made for bug#280649. There is deadlock in Browser3 unit tests.
I released a temporary fix for tomorrow's integration build. I still need find a proper fix. I might have to remove the changes for bug#280649 which would make WebStart apps completely broken again.
Thanks Silenio!
*** Bug 341608 has been marked as a duplicate of this bug. ***
It also causes a Font test deadlock in UI tests, using this week's I build I20110329-0800 PW
I fixed this problem by reverting the changes for bug#280649 and adding a workaround the will only prevent that specific deadlock. The workaround is to call gdk_threads_leave() after gtk_dialog_run() (and a couple of other calls). This will prevent the deadlock, but still leaves an open issue: both toolkits are accessing GTK concurrently without any synchornization which could lead to unpredictable problems like memory corruption. SWT uses its own lock to protect GTK/X. I believe SWT cannot use the GTK lock as is because it is not reentrant. For that locking system to work, all libraries in a multi-threaded application have to follow the rules describe in the GTK documentation. For example, they need to enter the lock in their idle/timer functions before calling a GTK function. http://www.gtk.org/api/2.6/gdk/gdk-Threads.html There is no way for SWT to determine if gdk_threads_enter() was called or not when handling a callback from libraries like XULRunner and WebKit. Currently these libraries do not call gdk_threads_enter() in there idle/timer functions. It is not clear to me this is a bug in these libraries because I am not sure they know that a GTK function is going to be called. The same callback could come from a event function (with the lock) or from a idle/timer function (without the lock). If it is the former, calling gdk_threads_enter() again will deadlock. If it is the later, not calling gdk_threads_enter() will leave the library unprotected. This would not be an issue if the lock was reentrant. The only solution I can see for both toolkits to synchronize their access to GTK properly is: the first toolkit to initialize GTK needs to replace the locking functions (by calling gdk_threads_set_locking_function()) with reentrant ones. That function has to be called before gdk_threads_init(). This solution requires changes in both toolkits. In the WebStart case, AWT is always the first toolkit to be initialized. So I do not see any way SWT can provide a fix for this.
The SWT tests DNF for build I20110405-0800 again. I confirmed the build contains this fix. The tests also finish properly when running in my local machine. I am not sure why it is not finishing in the build machine.
