[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-9427-gc2be6fc

[andersca at apple.com]

The following commit has been merged in the debian/experimental branch:
commit 95dd0b4fcaa18403987a312fd5f6b2c22afd2365
Author: andersca at apple.com <andersca at apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Thu Jul 15 18:39:37 2010 +0000

    WebKitTestRunner goes off the deep end, spinning in a dispatch queue thread
    https://bugs.webkit.org/show_bug.cgi?id=42355
    
    Reviewed by Darin Adler.
    
    Sometimes, when receiving a message whose size is very close to the inlineMessageMaxSize,
    mach_msg would return with MACH_RCV_TOO_LARGE. In debug builds we would assert, but in release
    builds we would just bail and the receiveSourceEventHandler would be run again shortly since we didn't
    actually pull the message off the mach message queue.
    
    Fix this by setting the receive source buffer size to include the maximum message trailer size, which
    mach_msg requires. Also, handle mach_msg returning MACH_RCV_TOO_LARGE (even though in theory it would never happen
    now that the receivedBufferSize always includes the maximum message trailer size.
    
    * Platform/CoreIPC/mac/ConnectionMac.cpp:
    (CoreIPC::Connection::receiveSourceEventHandler):
    Use a Vector with inline data instead of a char array. This way we can resize the Vector if the message received
    is too big.
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@63442 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebKit2/ChangeLog b/WebKit2/ChangeLog
index 9302306..7e1a57e 100644
--- a/WebKit2/ChangeLog
+++ b/WebKit2/ChangeLog
@@ -2,6 +2,27 @@
 
         Reviewed by Darin Adler.
 
+        WebKitTestRunner goes off the deep end, spinning in a dispatch queue thread
+        https://bugs.webkit.org/show_bug.cgi?id=42355
+
+        Sometimes, when receiving a message whose size is very close to the inlineMessageMaxSize,
+        mach_msg would return with MACH_RCV_TOO_LARGE. In debug builds we would assert, but in release
+        builds we would just bail and the receiveSourceEventHandler would be run again shortly since we didn't
+        actually pull the message off the mach message queue.
+
+        Fix this by setting the receive source buffer size to include the maximum message trailer size, which
+        mach_msg requires. Also, handle mach_msg returning MACH_RCV_TOO_LARGE (even though in theory it would never happen
+        now that the receivedBufferSize always includes the maximum message trailer size.
+
+        * Platform/CoreIPC/mac/ConnectionMac.cpp:
+        (CoreIPC::Connection::receiveSourceEventHandler):
+        Use a Vector with inline data instead of a char array. This way we can resize the Vector if the message received
+        is too big.
+
+2010-07-15  Anders Carlsson  <andersca at apple.com>
+
+        Reviewed by Darin Adler.
+
         Send JavaScript stream data to plug-ins
         https://bugs.webkit.org/show_bug.cgi?id=42384
 
diff --git a/WebKit2/Platform/CoreIPC/mac/ConnectionMac.cpp b/WebKit2/Platform/CoreIPC/mac/ConnectionMac.cpp
index efec2c8..652ab24 100644
--- a/WebKit2/Platform/CoreIPC/mac/ConnectionMac.cpp
+++ b/WebKit2/Platform/CoreIPC/mac/ConnectionMac.cpp
@@ -126,7 +126,6 @@ void Connection::sendOutgoingMessage(MessageID messageID, PassOwnPtr<ArgumentEnc
     }
     
     size_t messageSize = machMessageSize(arguments->bufferSize(), numberOfPortDescriptors, numberOfOOLMemoryDescriptors);
-    
     char buffer[inlineMessageMaxSize];
 
     bool messageBodyIsOOL = false;
@@ -277,21 +276,32 @@ static PassOwnPtr<ArgumentDecoder> createArgumentDecoder(mach_msg_header_t* head
 
 void Connection::receiveSourceEventHandler()
 {
-    char buffer[inlineMessageMaxSize];
+    // The receive buffer size should always include the maximum trailer size.
+    static const size_t receiveBufferSize = inlineMessageMaxSize + MAX_TRAILER_SIZE;
+
+    Vector<char, receiveBufferSize> buffer(receiveBufferSize);
     
-    mach_msg_header_t* header = reinterpret_cast<mach_msg_header_t*>(&buffer);
+    mach_msg_header_t* header = reinterpret_cast<mach_msg_header_t*>(buffer.data());
     
-    kern_return_t kr = mach_msg(header, MACH_RCV_MSG | MACH_RCV_LARGE | MACH_RCV_TIMEOUT, 0, sizeof(buffer), m_receivePort, 0, MACH_PORT_NULL);
+    kern_return_t kr = mach_msg(header, MACH_RCV_MSG | MACH_RCV_LARGE | MACH_RCV_TIMEOUT, 0, buffer.size(), m_receivePort, 0, MACH_PORT_NULL);
     if (kr == MACH_RCV_TIMED_OUT)
         return;
 
-    if (kr != MACH_MSG_SUCCESS) {
+    if (kr == MACH_RCV_TOO_LARGE) {
+        // The message was too large, resize the buffer and try again.
+        buffer.resize(header->msgh_size + MAX_TRAILER_SIZE);
+        
+        header = reinterpret_cast<mach_msg_header_t*>(buffer.data());
+        
+        kr = mach_msg(header, MACH_RCV_MSG | MACH_RCV_LARGE | MACH_RCV_TIMEOUT, 0, buffer.size(), m_receivePort, 0, MACH_PORT_NULL);
+        ASSERT(kr != MACH_RCV_TOO_LARGE);
+    }
 
+    if (kr != MACH_MSG_SUCCESS) {
         ASSERT_NOT_REACHED();
-        // FIXME: Handle MACH_RCV_MSG_TOO_LARGE.
         return;
     }
-    
+
     MessageID messageID = MessageID::fromInt(header->msgh_id);
     OwnPtr<ArgumentDecoder> arguments = createArgumentDecoder(header);
     ASSERT(arguments);

-- 
WebKit Debian packaging