[Webkit-unassigned] [Bug 63928] New: static destructors calling Timer.stop in wrong thread

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=63928

           Summary: static destructors calling Timer.stop in wrong thread
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: o.flebbe at science-computing.de


Created an attachment (id=99688)
 --> (https://bugs.webkit.org/attachment.cgi?id=99688&action=review)
Patch to allocate Timer on Heap, rather statically 

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. It is a bug exiting an SWT application using webkit.


The heart of the Problem is located in the way 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 libwebkit.so is loaded. 

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 an 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 is not be the thread which constructed the C++
Objects. At least for Java-SWT.

The patch supplied allocates the timers on heap, not statically before. 
Thus the destructors are not running on exit(), rather they are running when the threads ends its life. 

The second patch is to demonstrate the problem. Compile webkit with --enable-debug, run Programs/GtkLauncher and wait 10 seconds for webkit to crash.

I double checked the patch: It solves my SWT problem.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.