[SCM] WebKit Debian packaging branch, debian/experimental, updated. debian/1.3.8-1-1049-g2e11a8e

[commit-queue at webkit.org]

The following commit has been merged in the debian/experimental branch:
commit cb04dc7347f34da2f01b1e5aeee910c1630089a2
Author: commit-queue at webkit.org <commit-queue at webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Thu Dec 23 23:10:45 2010 +0000

    2010-12-23  Yongjun Zhang  <yongjun_zhang at apple.com>
    
            Reviewed by Darin Adler.
    
            WebKit crashes at DebuggerCallFrame::functionName() if m_callFrame is the top global callframe.
            https://bugs.webkit.org/show_bug.cgi?id=38535
    
            WebScriptDebugger in WebKit has empty implementations for willExecuteProgram and didExecuteProgram.  As a result,
            if the top call frame is from a program, WebKitScriptDebugger doesn't record that callframe as the top frame, and
            WebScriptDebugger's callframe stack is wrong from this point.  That could cause crash if we trying to access the top
            call frame from this stack when an exception throws because the saved top frame could be invalid.
    
            To fix that, we need to maintain the call frame stack in willExecuteProgram and didExecuteProgram, as we did in
            callEvent and returnEvent.
    
            * WebView/WebScriptDebugger.mm:
            (WebScriptDebugger::willExecuteProgram):
            (WebScriptDebugger::didExecuteProgram):
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@74586 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebKit/mac/ChangeLog b/WebKit/mac/ChangeLog
index 329743b..f7308f3 100644
--- a/WebKit/mac/ChangeLog
+++ b/WebKit/mac/ChangeLog
@@ -1,3 +1,22 @@
+2010-12-23  Yongjun Zhang  <yongjun_zhang at apple.com>
+
+        Reviewed by Darin Adler.
+
+        WebKit crashes at DebuggerCallFrame::functionName() if m_callFrame is the top global callframe.
+        https://bugs.webkit.org/show_bug.cgi?id=38535
+
+        WebScriptDebugger in WebKit has empty implementations for willExecuteProgram and didExecuteProgram.  As a result,
+        if the top call frame is from a program, WebKitScriptDebugger doesn't record that callframe as the top frame, and
+        WebScriptDebugger's callframe stack is wrong from this point.  That could cause crash if we trying to access the top
+        call frame from this stack when an exception throws because the saved top frame could be invalid.
+
+        To fix that, we need to maintain the call frame stack in willExecuteProgram and didExecuteProgram, as we did in
+        callEvent and returnEvent.
+
+        * WebView/WebScriptDebugger.mm:
+        (WebScriptDebugger::willExecuteProgram):
+        (WebScriptDebugger::didExecuteProgram):
+
 2010-12-22  Sam Weinig  <sam at webkit.org>
 
         Reviewed by Darin Adler.
diff --git a/WebKit/mac/WebView/WebScriptDebugger.mm b/WebKit/mac/WebView/WebScriptDebugger.mm
index f67b46f..25ef4b7 100644
--- a/WebKit/mac/WebView/WebScriptDebugger.mm
+++ b/WebKit/mac/WebView/WebScriptDebugger.mm
@@ -220,10 +220,12 @@ void WebScriptDebugger::exception(const DebuggerCallFrame& debuggerCallFrame, in
 
 void WebScriptDebugger::willExecuteProgram(const DebuggerCallFrame& debuggerCallFrame, intptr_t sourceID, int lineno)
 {
+    callEvent(debuggerCallFrame, sourceID, lineno);
 }
 
 void WebScriptDebugger::didExecuteProgram(const DebuggerCallFrame& debuggerCallFrame, intptr_t sourceID, int lineno)
 {
+    returnEvent(debuggerCallFrame, sourceID, lineno);
 }
 
 void WebScriptDebugger::didReachBreakpoint(const DebuggerCallFrame&, intptr_t, int)

-- 
WebKit Debian packaging