<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>120537</bug_id>
          
          <creation_ts>2013-08-30 10:04:58 -0700</creation_ts>
          <short_desc>Wrong for SlowPathCall to load callFrame reg from vm.topCallFrame after call</short_desc>
          <delta_ts>2013-09-09 16:02:22 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>JavaScriptCore</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Michael Saboff">msaboff</reporter>
          <assigned_to name="Michael Saboff">msaboff</assigned_to>
          
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>923039</commentid>
    <comment_count>0</comment_count>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2013-08-30 10:04:58 -0700</bug_when>
    <thetext>After making a slow path call in the exception path, we load the call frame register from vm.topCallFrame.  This isn&apos;t needed and wrong. The callFrame register is a callee save and therefore its contents will be preserved across the slow path call. Also, there are no guarantees that vm.topCallFrame is still valid.  Given these two facts, we actually need to be storing the callFrameRegister TO vm.topCallFrame.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>923043</commentid>
    <comment_count>1</comment_count>
      <attachid>210127</attachid>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2013-08-30 10:09:32 -0700</bug_when>
    <thetext>Created attachment 210127
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>923091</commentid>
    <comment_count>2</comment_count>
      <attachid>210127</attachid>
    <who name="Mark Lam">mark.lam</who>
    <bug_when>2013-08-30 11:14:51 -0700</bug_when>
    <thetext>Comment on attachment 210127
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=210127&amp;action=review

&gt; Source/JavaScriptCore/jit/SlowPathCall.h:91
&gt; -        m_jit-&gt;reloadCallFrameFromTopCallFrame();
&gt; +        m_jit-&gt;updateTopCallFrame();

This looks strange to me.  At this point, given that we have an exception, the caller may have unwound the stack already.  We should not assume that the current stack frame is even valid.  Have you tested against the tests in https://bugs.webkit.org/show_bug.cgi?id=119848 yet?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>924652</commentid>
    <comment_count>3</comment_count>
      <attachid>210127</attachid>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2013-09-04 15:44:57 -0700</bug_when>
    <thetext>Comment on attachment 210127
Patch

Michael, what&apos;s the right solution here?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>924657</commentid>
    <comment_count>4</comment_count>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2013-09-04 16:03:33 -0700</bug_when>
    <thetext>(In reply to comment #3)
&gt; (From update of attachment 210127 [details])
&gt; Michael, what&apos;s the right solution here?

I need to run the tests that Mark suggests to verify this change.

From what I&apos;ve seen, both locations have the same (correct) value.  It seem to make more sense that we update the one in vm.topCallFrame from the register.

I don&apos;t think Mark&apos;s concern is valid as this is the code that first discovers that there was an exception in the called C code.  Therefore there shouldn&apos;t have been any unwinding.  We&apos;re about ready to call ctiVMHandleException() which will call cti_vm_handle_exception() which will call jitThrow() which will unwind.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>926771</commentid>
    <comment_count>5</comment_count>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2013-09-09 10:25:39 -0700</bug_when>
    <thetext>(In reply to comment #2)
&gt; (From update of attachment 210127 [details])
&gt; View in context: https://bugs.webkit.org/attachment.cgi?id=210127&amp;action=review
&gt; 
&gt; &gt; Source/JavaScriptCore/jit/SlowPathCall.h:91
&gt; &gt; -        m_jit-&gt;reloadCallFrameFromTopCallFrame();
&gt; &gt; +        m_jit-&gt;updateTopCallFrame();
&gt; 
&gt; This looks strange to me.  At this point, given that we have an exception, the caller may have unwound the stack already.  We should not assume that the current stack frame is even valid.  Have you tested against the tests in https://bugs.webkit.org/show_bug.cgi?id=119848 yet?

I tested the patch with w276-reduced.js attached to https://bugs.webkit.org/show_bug.cgi?id=119848 and it worked fine.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>926949</commentid>
    <comment_count>6</comment_count>
      <attachid>210127</attachid>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2013-09-09 15:26:05 -0700</bug_when>
    <thetext>Comment on attachment 210127
Patch

r=me</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>926965</commentid>
    <comment_count>7</comment_count>
      <attachid>210127</attachid>
    <who name="Oliver Hunt">oliver</who>
    <bug_when>2013-09-09 15:42:49 -0700</bug_when>
    <thetext>Comment on attachment 210127
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=210127&amp;action=review

&gt;&gt;&gt; Source/JavaScriptCore/jit/SlowPathCall.h:91
&gt;&gt;&gt; +        m_jit-&gt;updateTopCallFrame();
&gt;&gt; 
&gt;&gt; This looks strange to me.  At this point, given that we have an exception, the caller may have unwound the stack already.  We should not assume that the current stack frame is even valid.  Have you tested against the tests in https://bugs.webkit.org/show_bug.cgi?id=119848 yet?
&gt; 
&gt; I tested the patch with w276-reduced.js attached to https://bugs.webkit.org/show_bug.cgi?id=119848 and it worked fine.

Mark, we cannot unwind the stack through host code - if execution is returning to js we have by definition rolled back only as far the the frame we&apos;re moving into.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>926974</commentid>
    <comment_count>8</comment_count>
    <who name="Michael Saboff">msaboff</who>
    <bug_when>2013-09-09 16:02:22 -0700</bug_when>
    <thetext>Committed r155399: &lt;http://trac.webkit.org/changeset/155399&gt;</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>210127</attachid>
            <date>2013-08-30 10:09:32 -0700</date>
            <delta_ts>2013-09-09 15:42:48 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>120537.patch</filename>
            <type>text/plain</type>
            <size>2515</size>
            <attacher name="Michael Saboff">msaboff</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291
cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTU0ODkyKQorKysgU291cmNl
L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE4IEBA
CisyMDEzLTA4LTMwICBNaWNoYWVsIFNhYm9mZiAgPG1zYWJvZmZAYXBwbGUuY29tPgorCisgICAg
ICAgIFdyb25nIGZvciBTbG93UGF0aENhbGwgdG8gbG9hZCBjYWxsRnJhbWUgcmVnIGZyb20gdm0u
dG9wQ2FsbEZyYW1lIGFmdGVyIGNhbGwKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv
c2hvd19idWcuY2dpP2lkPTEyMDUzNworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q
UyEpLgorCisgICAgICAgIENoYW5nZWQgSklUU2xvd1BhdGhDYWxsOjpjYWxsKCkgdG8gdXBkYXRl
IHZtLnRvcENhbGxGcmFtZSBmcm9tIHRoZSBjYWxsRnJhbWVSZWdpc3RlciBpbnN0ZWFkIG9mIHRo
ZQorICAgICAgICBvdGhlciB3YXkgYXJvdW5kLgorCisgICAgICAgICogaml0L0pJVC5oOgorICAg
ICAgICAqIGppdC9KSVRJbmxpbmVzLmg6CisgICAgICAgICogaml0L1Nsb3dQYXRoQ2FsbC5oOgor
ICAgICAgICAoSlNDOjpKSVRTbG93UGF0aENhbGw6OmNhbGwpOgorCiAyMDEzLTA4LTMwICBDaHJp
cyBDdXJ0aXMgIDxjaHJpc19jdXJ0aXNAYXBwbGUuY29tPgogCiAgICAgICAgIENsZWFuaW5nIGVy
cm9yRGVzY3JpcHRpb25Gb3JWYWx1ZSBhZnRlciByMTU0ODM5CkluZGV4OiBTb3VyY2UvSmF2YVNj
cmlwdENvcmUvaml0L0pJVC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9q
aXQvSklULmgJKHJldmlzaW9uIDE1NDg0NSkKKysrIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQv
SklULmgJKHdvcmtpbmcgY29weSkKQEAgLTgzOCw3ICs4MzgsNiBAQCBuYW1lc3BhY2UgSlNDIHsK
IAogICAgICAgICB2b2lkIHJlc3RvcmVBcmd1bWVudFJlZmVyZW5jZUZvclRyYW1wb2xpbmUoKTsK
ICAgICAgICAgdm9pZCB1cGRhdGVUb3BDYWxsRnJhbWUoKTsKLSAgICAgICAgdm9pZCByZWxvYWRD
YWxsRnJhbWVGcm9tVG9wQ2FsbEZyYW1lKCk7CiAKICAgICAgICAgQ2FsbCBlbWl0TmFrZWRDYWxs
KENvZGVQdHIgZnVuY3Rpb24gPSBDb2RlUHRyKCkpOwogCkluZGV4OiBTb3VyY2UvSmF2YVNjcmlw
dENvcmUvaml0L0pJVElubGluZXMuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvSmF2YVNjcmlwdENv
cmUvaml0L0pJVElubGluZXMuaAkocmV2aXNpb24gMTU0ODQ1KQorKysgU291cmNlL0phdmFTY3Jp
cHRDb3JlL2ppdC9KSVRJbmxpbmVzLmgJKHdvcmtpbmcgY29weSkKQEAgLTE5MSwxMSArMTkxLDYg
QEAgQUxXQVlTX0lOTElORSB2b2lkIEpJVDo6dXBkYXRlVG9wQ2FsbEZyYQogICAgIHN0b3JlUHRy
KGNhbGxGcmFtZVJlZ2lzdGVyLCAmbV92bS0+dG9wQ2FsbEZyYW1lKTsKIH0KIAotQUxXQVlTX0lO
TElORSB2b2lkIEpJVDo6cmVsb2FkQ2FsbEZyYW1lRnJvbVRvcENhbGxGcmFtZSgpCi17Ci0gICAg
bG9hZFB0cigmbV92bS0+dG9wQ2FsbEZyYW1lLCBjYWxsRnJhbWVSZWdpc3Rlcik7Ci19Ci0KIEFM
V0FZU19JTkxJTkUgdm9pZCBKSVQ6OnJlc3RvcmVBcmd1bWVudFJlZmVyZW5jZUZvclRyYW1wb2xp
bmUoKQogewogI2lmIENQVShYODYpCkluZGV4OiBTb3VyY2UvSmF2YVNjcmlwdENvcmUvaml0L1Ns
b3dQYXRoQ2FsbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvU2xv
d1BhdGhDYWxsLmgJKHJldmlzaW9uIDE1NDg0NSkKKysrIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9q
aXQvU2xvd1BhdGhDYWxsLmgJKHdvcmtpbmcgY29weSkKQEAgLTg4LDcgKzg4LDcgQEAgcHVibGlj
OgogI2Vsc2UKICAgICAgICAgSklUOjpKdW1wIG5vRXhjZXB0aW9uID0gbV9qaXQtPmJyYW5jaFRl
c3Q2NChKSVQ6Olplcm8sIEpJVDo6QWJzb2x1dGVBZGRyZXNzKG1faml0LT5tX2NvZGVCbG9jay0+
dm0oKS0+YWRkcmVzc09mRXhjZXB0aW9uKCkpKTsKICNlbmRpZgotICAgICAgICBtX2ppdC0+cmVs
b2FkQ2FsbEZyYW1lRnJvbVRvcENhbGxGcmFtZSgpOworICAgICAgICBtX2ppdC0+dXBkYXRlVG9w
Q2FsbEZyYW1lKCk7CiAgICAgICAgIG1faml0LT5tb3ZlKEpJVDo6VHJ1c3RlZEltbVB0cihGdW5j
dGlvblB0cihjdGlWTUhhbmRsZUV4Y2VwdGlvbikudmFsdWUoKSksIEpJVDo6cmVnVDEpOwogICAg
ICAgICBtX2ppdC0+anVtcChKSVQ6OnJlZ1QxKTsKICAgICAgICAgbm9FeGNlcHRpb24ubGluayht
X2ppdCk7Cg==
</data>
<flag name="review"
          id="232222"
          type_id="1"
          status="+"
          setter="ggaren"
    />
          </attachment>
      

    </bug>

</bugzilla>