Title: [165876] releases/WebKitGTK/webkit-2.4/Source/WebKit2
Revision
165876
Author
carlo...@webkit.org
Date
2014-03-19 00:14:32 -0700 (Wed, 19 Mar 2014)

Log Message

Merge r165812 - [GTK] Race condition when the socket event source is cancelled
https://bugs.webkit.org/show_bug.cgi?id=130395

Reviewed by Martin Robinson.

In some cases when the socket event source is cancelled the socket
event source callback is called with the condition of the previous
poll instead of 0. This can happen sometimes when the source is
cancelled from the socket event source callback. Once the socket
event source is cancelled, it's dispatched by glib without
polling, so the condition is never reset again and the callback is
called again and again with the previous condition. When the
condition is G_IO_IN, the source is re-scheduled entering into an
infinite loop. We should always check if the source has been
cancelled at the beginning of the callback to destroy the source
instead of relying on the condition being 0.

* Platform/gtk/WorkQueueGtk.cpp:
(WorkQueue::SocketEventSource::isCancelled):
(WorkQueue::SocketEventSource::eventCallback):

Modified Paths

Diff

Modified: releases/WebKitGTK/webkit-2.4/Source/WebKit2/ChangeLog (165875 => 165876)


--- releases/WebKitGTK/webkit-2.4/Source/WebKit2/ChangeLog	2014-03-19 07:13:37 UTC (rev 165875)
+++ releases/WebKitGTK/webkit-2.4/Source/WebKit2/ChangeLog	2014-03-19 07:14:32 UTC (rev 165876)
@@ -1,3 +1,26 @@
+2014-03-18  Carlos Garcia Campos  <cgar...@igalia.com>
+
+        [GTK] Race condition when the socket event source is cancelled
+        https://bugs.webkit.org/show_bug.cgi?id=130395
+
+        Reviewed by Martin Robinson.
+
+        In some cases when the socket event source is cancelled the socket
+        event source callback is called with the condition of the previous
+        poll instead of 0. This can happen sometimes when the source is
+        cancelled from the socket event source callback. Once the socket
+        event source is cancelled, it's dispatched by glib without
+        polling, so the condition is never reset again and the callback is
+        called again and again with the previous condition. When the
+        condition is G_IO_IN, the source is re-scheduled entering into an
+        infinite loop. We should always check if the source has been
+        cancelled at the beginning of the callback to destroy the source
+        instead of relying on the condition being 0.
+
+        * Platform/gtk/WorkQueueGtk.cpp:
+        (WorkQueue::SocketEventSource::isCancelled):
+        (WorkQueue::SocketEventSource::eventCallback):
+
 2014-03-17  Giovanni Campagna  <gcampa...@src.gnome.org>
 
         [GTK] Don't busy loop when the socket is full

Modified: releases/WebKitGTK/webkit-2.4/Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp (165875 => 165876)


--- releases/WebKitGTK/webkit-2.4/Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp	2014-03-19 07:13:37 UTC (rev 165875)
+++ releases/WebKitGTK/webkit-2.4/Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp	2014-03-19 07:14:32 UTC (rev 165876)
@@ -87,11 +87,21 @@
         m_closeFunction();
     }
 
-    static gboolean eventCallback(GSocket* socket, GIOCondition condition, SocketEventSource* eventSource)
+    bool isCancelled() const
     {
+        return g_cancellable_is_cancelled(m_cancellable);
+    }
+
+    static gboolean eventCallback(GSocket*, GIOCondition condition, SocketEventSource* eventSource)
+    {
         ASSERT(eventSource);
 
-        if (condition & G_IO_HUP || condition & G_IO_ERR) {
+        if (eventSource->isCancelled()) {
+            // EventSource has been cancelled, return FALSE to destroy the source.
+            return FALSE;
+        }
+
+        if (condition & G_IO_HUP || condition & G_IO_ERR || condition & G_IO_NVAL) {
             eventSource->didClose();
             return FALSE;
         }
@@ -101,7 +111,7 @@
             return TRUE;
         }
 
-        // EventSource has been cancelled, return FALSE to destroy the source.
+        ASSERT_NOT_REACHED();
         return FALSE;
     }
 
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to