[webkit-gtk] [Patch/Workaround] for gtk webkit as used by SWT

[Olaf Flebbe]

Hi,

I have filed a problem with the latest eclipse indigo release for Fedora
15 at https://bugs.eclipse.org/bugs/show_bug.cgi?id=348746
I have the same problem on opensuse 11.4.


I am using the webkit Source RPM to reproduce the problem but found the
offending code is the essentially the same on webkit-nightly. I was not
able to build webkit nightly because of the libsoup issues mentioned
here before.

To reproduce the problem in Short: Use FC15 oder opensuse 11.4 with all
defaults (preinstalled libwebkitgtk, openjdk, etc). Download current
eclipse, show HTML help, quit eclipse and crash most of the time --or --
Use SWT Browser Demo (jar in the eclipse bugtracker) and finish it
(sometimes crashing).

After some investigation it seems IMHO to be a gtk webkit problem:
Here is some kind of workaround for libwebkitgtk. But the real problem
is triggered by how java uses webkit-gtk in SWT.

In WebKit Timers Source/WebCore/platform/Timers.cpp are intermixed with
Threads. It is not possible to stop() a Timer in a different thread than
the one it was created in. Timers are thread specific by design.

Thus Timers own an internal data structure referenced through TLS
(Thread local storage). (The ThreadSpecific<ThreadGlobalData> class),
organizing all the Timeres of the current Thread.

There is a static allocated Timer used by the Cairo backend:
PurgeScratchBufferTimer in
Source/WebCore/platform/graphics/cairo/ContextShadowCairo.cpp

This Timer is allocated when java is loading the JNI/SWT/gtk libraries,
by the current thread, which happens _not_ to be the _main_ thread.

This PurgeScratchBufferTimer is constructed at the time libwebkitgtk is
loaded into SWT and may be used later on.

What happens if a SWT examples exits()?

The libc Runtime runs all the static destructors, including those
objects located in the shared libraries. And it runs these destructors
within the thread calling exit()!

But this exit()ed thread may not be the thread which constructed the C++
Objects. At least for Java-SWT.

The "REAL PATCH" would be to ensure Timers are stopped in all Threads
prior destructing anything. AFAIK this is very difficult to ensure in java.

The proposed patch is to short-circuit Timer destruction for the case
currentThread() != construction time thread. Unfortunately some of the
elegance of the Timer Class in Webkit breaks down (the need of the
m_thread member).

Cheers
Olaf

--- /home/flebbe/tmp/WebKit-r89772/Source/WebCore/platform/Timer.cpp
2011-01-09 10:48:10.000000000 +0100
+++ webkit-1.3.10/Source/WebCore/platform/Timer.cpp	2011-06-27
18:41:13.000000000 +0200
@@ -164,16 +164,20 @@
     : m_nextFireTime(0)
     , m_repeatInterval(0)
     , m_heapIndex(-1)
-#ifndef NDEBUG
     , m_thread(currentThread())
-#endif
 {
 }

 TimerBase::~TimerBase()
 {
+  // In case a static destructor is called
+  // we cannot be sure we are on the correct thread
+  // Since we are exiting anyway, simply use a short-circuit.
+  // This is a SWT workaround
+  if (m_thread == currentThread()) {
     stop();
     ASSERT(!inHeap());
+  }
 }

 void TimerBase::start(double nextFireInterval, double repeatInterval)




-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: o_flebbe.vcf
Type: text/x-vcard
Size: 347 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20110628/c4aaa627/attachment-0001.vcf>