<?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>25394</bug_id>
          
          <creation_ts>2009-04-25 09:08:49 -0700</creation_ts>
          <short_desc>REGRESSION: crash in DocumentLoader::addResponse due to bad |this| pointer</short_desc>
          <delta_ts>2009-05-13 12:17:06 -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>Page Loading</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Windows XP</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>Regression</keywords>
          <priority>P1</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Darin Fisher (:fishd, Google)">fishd</reporter>
          <assigned_to name="David Levin">levin</assigned_to>
          <cc>andersca</cc>
    
    <cc>ap</cc>
    
    <cc>darin</cc>
    
    <cc>levin</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>118838</commentid>
    <comment_count>0</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-25 09:08:49 -0700</bug_when>
    <thetext>CRASH in DocumentLoader::addResponse due to bad |this| pointer

This is possibly a regression since we have started to see it show up with greater frequency in our automated reliability testing as well as in end-user crash reports.

Here&apos;s the relevant portion of the stack:

chrome_2390000!WebCore::DocumentLoader::addResponse+0x3 [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\documentloader.cpp @ 670]
chrome_2390000!WebCore::FrameLoader::didReceiveResponse+0x1f [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp @ 3729]
chrome_2390000!WebCore::ResourceLoader::didReceiveResponse+0x8c [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp @ 243]
chrome_2390000!WebCore::SubresourceLoader::didReceiveResponse+0x80 [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\subresourceloader.cpp @ 144]
chrome_2390000!WebCore::ResourceLoader::didReceiveResponse+0xe [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp @ 407]
chrome_2390000!WebCore::ResourceHandleInternal::OnReceivedResponse+0xc0 [c:\b\slave\chromium-rel-xp\build\src\webkit\glue\resource_handle_impl.cc @ 547]
chrome_2390000!ResourceDispatcher::OnReceivedResponse+0x93 [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @ 368]
&lt;snip... called from an incoming IPC message&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118839</commentid>
    <comment_count>1</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-25 09:26:31 -0700</bug_when>
    <thetext>The corresponding chromium bug report:
http://code.google.com/p/chromium/issues/detail?id=9947</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118887</commentid>
    <comment_count>2</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 00:19:42 -0700</bug_when>
    <thetext>This turns out to be a variant of another crash I recently patched.  See bug 25136.

If a subresource like an IMG is requested after &apos;unload&apos; but before the next page load completes, it can result in this crash.  The IMG load has to complete very quickly, which can be synthesized by loading a data URL.

Test case coming up.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118888</commentid>
    <comment_count>3</comment_count>
      <attachid>29800</attachid>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 00:23:13 -0700</bug_when>
    <thetext>Created attachment 29800
testcase1 - inner frame</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118889</commentid>
    <comment_count>4</comment_count>
      <attachid>29801</attachid>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 00:24:25 -0700</bug_when>
    <thetext>Created attachment 29801
testcase1 - outer frame (load this to run test)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118891</commentid>
    <comment_count>5</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 00:26:12 -0700</bug_when>
    <thetext>This crashes both Safari 4 and Chrome 2.  By contrast, Safari 3 and Chrome 1 are fine.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118892</commentid>
    <comment_count>6</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 00:41:41 -0700</bug_when>
    <thetext>We could probably hack around this crash, but I think there is a bigger problem at play here.  It seems like we should not allow any resource requests to begin after the closeURL() call in FrameLoader::detachFromParent().

For reference:  The new resource requests are generated from within stopAllLoaders.  There may be more than one way to achieve this, but the trick I am using is to define an onabort handler on a XMLHttpRequest that I start in my unload handler.  The onabort handler then starts another resource load.  That resource load should not be allowed.  Or, maybe we should not even fire event handlers at all after unload.  Thoughts?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118902</commentid>
    <comment_count>7</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-04-26 06:23:17 -0700</bug_when>
    <thetext>Is onabort dispatched asynchronously? XMLHttpRequest used to not start from onunload, see bug 10904.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118904</commentid>
    <comment_count>8</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-04-26 07:14:02 -0700</bug_when>
    <thetext>&gt; Is onabort dispatched asynchronously? XMLHttpRequest used to not start from
&gt; onunload, see bug 10904.

onabort is dispatched synchronously.  that bug is a little vague.  i don&apos;t have any trouble starting an XHR from unload.  what happens is that the request is aborted immediately afterwards when the containing IFRAME object is removed from the DOM.  this is why my testcase involves an inner frame.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118907</commentid>
    <comment_count>9</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-04-26 07:43:21 -0700</bug_when>
    <thetext>(In reply to comment #8)
&gt; onabort is dispatched synchronously.  that bug is a little vague.  i don&apos;t have
&gt; any trouble starting an XHR from unload. 

I see, it changed since that bug was filed - the loader refused to start loading then.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>120916</commentid>
    <comment_count>10</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-05-12 12:12:08 -0700</bug_when>
    <thetext>&gt; I see, it changed since that bug was filed - the loader refused to start
&gt; loading then.

I think the right fix here is to change the loader to refuse to start loading after unload.  The trick is to find out when to allow loading to start again.  I think we have to allow navigations of the frame itself, and we have to re-enable subresource loads once we transition to the committed state.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>120920</commentid>
    <comment_count>11</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-05-12 12:14:49 -0700</bug_when>
    <thetext>Also note this comment in ResourceHandleMac.mm:

    // If we are no longer attached to a Page, this must be an attempted load from an
    // onUnload handler, so let&apos;s just block it.
    Page* page = frame-&gt;page();
    if (!page)
        return false;

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>120923</commentid>
    <comment_count>12</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-05-12 13:01:15 -0700</bug_when>
    <thetext>&gt; Also note this comment in ResourceHandleMac.mm:

Interesting.  I guess it is OK that ResourceHandleMac still allows synchronous XHR.

We can easily implement this same fix in the other ResourceHandle implementations.  Does that sound like the right solution to you?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>120924</commentid>
    <comment_count>13</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-05-12 13:05:34 -0700</bug_when>
    <thetext>Hmm... I just ran my testcase using Safari 4 on Mac, and it also crashes.  Maybe there is more that we need to do...
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>120991</commentid>
    <comment_count>14</comment_count>
      <attachid>30263</attachid>
    <who name="David Levin">levin</who>
    <bug_when>2009-05-13 00:14:39 -0700</bug_when>
    <thetext>Created attachment 30263
proposed fix.

Working on converting the attached files into a layout test before submitting for review.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121021</commentid>
    <comment_count>15</comment_count>
      <attachid>30263</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2009-05-13 06:22:32 -0700</bug_when>
    <thetext>Comment on attachment 30263
proposed fix.

&gt;      if (!skipCanLoadCheck
&gt; -            &amp;&amp; FrameLoader::restrictAccessToLocal()
&gt; -            &amp;&amp; !FrameLoader::canLoad(request.url(), String(), frame-&gt;document())) {
&gt; +        &amp;&amp; FrameLoader::restrictAccessToLocal()
&gt; +        &amp;&amp; !FrameLoader::canLoad(request.url(), String(), frame-&gt;document())) {
&gt;          FrameLoader::reportLocalLoadFailed(frame, request.url().string());
&gt;          return 0;
&gt;      }

This code is intentionally indented this way, so the if statement conditions don&apos;t line up with the if statement body. Please don&apos;t reformat it. We could discuss preferred style for cases like this and put it in the style guide document, but in the mean time it would be better not to make this change, which is unrelated to your fix.

If the formatting really does bother you and you want to sidestep it in another way, you can restructure the code so we don&apos;t have a long if statement like this, perhaps by introducing another boolean.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121022</commentid>
    <comment_count>16</comment_count>
      <attachid>30263</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2009-05-13 06:22:54 -0700</bug_when>
    <thetext>Comment on attachment 30263
proposed fix.

Fix looks good, by the way.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121030</commentid>
    <comment_count>17</comment_count>
    <who name="David Levin">levin</who>
    <bug_when>2009-05-13 07:40:18 -0700</bug_when>
    <thetext>Re: formatting:  No problem. I&apos;ll undo the formatting change when I add the patch with the layout test. 

I simply thought it was a mistake.  Thanks for the info.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121036</commentid>
    <comment_count>18</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-05-13 08:40:50 -0700</bug_when>
    <thetext>It looks like m_isStopping will be set to true when FrameLoader::stopAllLoaders is called.  That gets called when the user hits the stop button and/or initiates a download on a page.  In those cases, we don&apos;t unload the page, and we don&apos;t want to suppress further subresource loads.

That said, I haven&apos;t tested this... but I worry the change could be wrong.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121038</commentid>
    <comment_count>19</comment_count>
    <who name="Darin Fisher (:fishd, Google)">fishd</who>
    <bug_when>2009-05-13 08:42:28 -0700</bug_when>
    <thetext>&gt; That said, I haven&apos;t tested this... but I worry the change could be wrong.

Doh, I realize now that m_isStopping is toggled back to false a little while later.  Then my concerns are ill founded.  Sorry for the spam.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121063</commentid>
    <comment_count>20</comment_count>
      <attachid>30280</attachid>
    <who name="David Levin">levin</who>
    <bug_when>2009-05-13 10:52:47 -0700</bug_when>
    <thetext>Created attachment 30280
Proposed fix with layout test.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>121071</commentid>
    <comment_count>21</comment_count>
    <who name="David Levin">levin</who>
    <bug_when>2009-05-13 12:17:06 -0700</bug_when>
    <thetext>Committed http://trac.webkit.org/changeset/43650.
</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>29800</attachid>
            <date>2009-04-26 00:23:13 -0700</date>
            <delta_ts>2009-04-26 00:23:13 -0700</delta_ts>
            <desc>testcase1 - inner frame</desc>
            <filename>unload_win.html</filename>
            <type>text/html</type>
            <size>329</size>
            <attacher name="Darin Fisher (:fishd, Google)">fishd</attacher>
            
              <data encoding="base64">PHNjcmlwdD4KdmFyIHJlcXVlc3RzID0gW107CmZ1bmN0aW9uIHN0YXJ0KCkgewogIHZhciB4ID0g
bmV3IFhNTEh0dHBSZXF1ZXN0KCk7CiAgeC5vcGVuKCJHRVQiLCBsb2NhdGlvbiwgdHJ1ZSAvKiBh
c3luYyAqLyk7CiAgeC5vbmFib3J0ID0gc3RhcnQyOwogIHguc2VuZChudWxsKTsKICByZXF1ZXN0
cy5wdXNoKHgpOwp9CmZ1bmN0aW9uIHN0YXJ0MigpIHsKICBpbWcgPSBuZXcgSW1hZ2UoKTsKICBp
bWcuc3JjID0gImRhdGE6LGZvbyI7CiAgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChpbWcpOwp9
Cjwvc2NyaXB0Pgo8Ym9keSBvbnVubG9hZD0ic3RhcnQoKSI+PC9ib2R5Pgo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>29801</attachid>
            <date>2009-04-26 00:24:25 -0700</date>
            <delta_ts>2009-04-26 00:24:25 -0700</delta_ts>
            <desc>testcase1 - outer frame (load this to run test)</desc>
            <filename>unload.html</filename>
            <type>text/html</type>
            <size>129</size>
            <attacher name="Darin Fisher (:fishd, Google)">fishd</attacher>
            
              <data encoding="base64">PGJvZHk+CjxpZnJhbWUgc3JjPSIvYXR0YWNobWVudC5jZ2k/aWQ9Mjk4MDAiPjwvaWZyYW1lPgo8
YnV0dG9uIG9uY2xpY2s9ImxvY2F0aW9uPSdhYm91dDpibGFuayciPmNsaWNrIHRvIGNyYXNoPC9i
dXR0b24+CjwvYm9keT4K
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>30263</attachid>
            <date>2009-05-13 00:14:39 -0700</date>
            <delta_ts>2009-05-13 10:52:47 -0700</delta_ts>
            <desc>proposed fix.</desc>
            <filename>bug25394.txt</filename>
            <type>text/plain</type>
            <size>1012</size>
            <attacher name="David Levin">levin</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1dlYkNvcmUvbG9hZGVyL1N1YnJlc291cmNlTG9hZGVyLmNwcCBiL1dlYkNv
cmUvbG9hZGVyL1N1YnJlc291cmNlTG9hZGVyLmNwcAppbmRleCA4MjRjODNjLi5lNzI0MmVlIDEw
MDY0NAotLS0gYS9XZWJDb3JlL2xvYWRlci9TdWJyZXNvdXJjZUxvYWRlci5jcHAKKysrIGIvV2Vi
Q29yZS9sb2FkZXIvU3VicmVzb3VyY2VMb2FkZXIuY3BwCkBAIC02NiwxNCArNjYsMTQgQEAgUGFz
c1JlZlB0cjxTdWJyZXNvdXJjZUxvYWRlcj4gU3VicmVzb3VyY2VMb2FkZXI6OmNyZWF0ZShGcmFt
ZSogZnJhbWUsIFN1YnJlc291cmMKICAgICAgICAgcmV0dXJuIDA7CiAKICAgICBGcmFtZUxvYWRl
ciogZmwgPSBmcmFtZS0+bG9hZGVyKCk7Ci0gICAgaWYgKCFza2lwQ2FuTG9hZENoZWNrICYmIGZs
LT5zdGF0ZSgpID09IEZyYW1lU3RhdGVQcm92aXNpb25hbCkKKyAgICBpZiAoIXNraXBDYW5Mb2Fk
Q2hlY2sgJiYgKGZsLT5zdGF0ZSgpID09IEZyYW1lU3RhdGVQcm92aXNpb25hbCB8fCBmbC0+YWN0
aXZlRG9jdW1lbnRMb2FkZXIoKS0+aXNTdG9wcGluZygpKSkKICAgICAgICAgcmV0dXJuIDA7CiAK
ICAgICBSZXNvdXJjZVJlcXVlc3QgbmV3UmVxdWVzdCA9IHJlcXVlc3Q7CiAKICAgICBpZiAoIXNr
aXBDYW5Mb2FkQ2hlY2sKLSAgICAgICAgICAgICYmIEZyYW1lTG9hZGVyOjpyZXN0cmljdEFjY2Vz
c1RvTG9jYWwoKQotICAgICAgICAgICAgJiYgIUZyYW1lTG9hZGVyOjpjYW5Mb2FkKHJlcXVlc3Qu
dXJsKCksIFN0cmluZygpLCBmcmFtZS0+ZG9jdW1lbnQoKSkpIHsKKyAgICAgICAgJiYgRnJhbWVM
b2FkZXI6OnJlc3RyaWN0QWNjZXNzVG9Mb2NhbCgpCisgICAgICAgICYmICFGcmFtZUxvYWRlcjo6
Y2FuTG9hZChyZXF1ZXN0LnVybCgpLCBTdHJpbmcoKSwgZnJhbWUtPmRvY3VtZW50KCkpKSB7CiAg
ICAgICAgIEZyYW1lTG9hZGVyOjpyZXBvcnRMb2NhbExvYWRGYWlsZWQoZnJhbWUsIHJlcXVlc3Qu
dXJsKCkuc3RyaW5nKCkpOwogICAgICAgICByZXR1cm4gMDsKICAgICB9Cg==
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>30280</attachid>
            <date>2009-05-13 10:52:47 -0700</date>
            <delta_ts>2009-05-13 10:59:24 -0700</delta_ts>
            <desc>Proposed fix with layout test.</desc>
            <filename>bug25394.txt</filename>
            <type>text/plain</type>
            <size>5441</size>
            <attacher name="David Levin">levin</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv
ZwppbmRleCAyZjY5ZWIwLi5mNjliODBhIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM
b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTcgQEAKKzIwMDktMDUt
MTMgIERhdmlkIExldmluICA8bGV2aW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2Vk
IGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEJ1ZyAyNTM5NDogUkVHUkVTU0lPTjogY3Jh
c2ggaW4gRG9jdW1lbnRMb2FkZXI6OmFkZFJlc3BvbnNlIGR1ZSB0byBiYWQgfHRoaXN8IHBvaW50
ZXIKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI1Mzk0
CisKKyAgICAgICAgUmVxdWVzdCBhIHN1YnJlc291cmNlIGxvYWQgZm9yIGFuIElNRyBhZnRlciAn
dW5sb2FkJyBhbmQgYmVmb3JlIHRoZSBuZXh0CisgICAgICAgIHBhZ2UgbG9hZCBjb21wbGV0ZXMg
dG8gZXhwb3NlIHRoZSBjcmFzaC4KKworICAgICAgICAqIGh0dHAvdGVzdHMveG1saHR0cHJlcXVl
c3QvZnJhbWUtdW5sb2FkLWFib3J0LWNyYXNoLWV4cGVjdGVkLnR4dDogQWRkZWQuCisgICAgICAg
ICogaHR0cC90ZXN0cy94bWxodHRwcmVxdWVzdC9mcmFtZS11bmxvYWQtYWJvcnQtY3Jhc2guaHRt
bDogQWRkZWQuCisgICAgICAgICogaHR0cC90ZXN0cy94bWxodHRwcmVxdWVzdC9yZXNvdXJjZXMv
eG1saHR0cHJlcXVlc3QtaW4tdW5sb2FkLmh0bWw6IEFkZGVkLgorCiAyMDA5LTA1LTEyICBSb2xh
bmQgU3RlaW5lciA8cm9sYW5kc3RlaW5lckBnb29nbGUuY29tPgogCiAgICAgICAgIFJldmlld2Vk
IGJ5IEVyaWMgU2VpZGVsLgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy94bWxo
dHRwcmVxdWVzdC9mcmFtZS11bmxvYWQtYWJvcnQtY3Jhc2gtZXhwZWN0ZWQudHh0IGIvTGF5b3V0
VGVzdHMvaHR0cC90ZXN0cy94bWxodHRwcmVxdWVzdC9mcmFtZS11bmxvYWQtYWJvcnQtY3Jhc2gt
ZXhwZWN0ZWQudHh0Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjZiYmE5YjAK
LS0tIC9kZXYvbnVsbAorKysgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL3htbGh0dHByZXF1ZXN0
L2ZyYW1lLXVubG9hZC1hYm9ydC1jcmFzaC1leHBlY3RlZC50eHQKQEAgLTAsMCArMSw4IEBACitm
cmFtZSAiPCEtLWZyYW1lUGF0aCAvLzwhLS1mcmFtZTAtLT4tLT4iIC0gaGFzIDEgb251bmxvYWQg
aGFuZGxlcihzKQorVGVzdCBmb3IgYnVnIDI1Mzk0OiBjcmFzaCBpbiBEb2N1bWVudExvYWRlcjo6
YWRkUmVzcG9uc2UgZHVlIHRvIGJhZCB8dGhpc3wgcG9pbnRlcgorCitZb3Ugc2hvdWxkIHNlZSBh
IGZldyBtZXNzYWdlcyBmb2xsb3dlZCBieSBQQVNTRUQgb25jZS4KKworUmVhZHkgU3RhdGU6IDEK
K1JlYWR5IFN0YXRlOiA0CitQQVNTRUQKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvdGVz
dHMveG1saHR0cHJlcXVlc3QvZnJhbWUtdW5sb2FkLWFib3J0LWNyYXNoLmh0bWwgYi9MYXlvdXRU
ZXN0cy9odHRwL3Rlc3RzL3htbGh0dHByZXF1ZXN0L2ZyYW1lLXVubG9hZC1hYm9ydC1jcmFzaC5o
dG1sCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjIyOGU3YjYKLS0tIC9kZXYv
bnVsbAorKysgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL3htbGh0dHByZXF1ZXN0L2ZyYW1lLXVu
bG9hZC1hYm9ydC1jcmFzaC5odG1sCkBAIC0wLDAgKzEsNDIgQEAKKzxodG1sPgorPGJvZHk+Cis8
cD5UZXN0IGZvciA8YSBocmVmPSJodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/
aWQ9MjUzOTQiPmJ1ZyAyNTM5NDwvYT46IGNyYXNoIGluIERvY3VtZW50TG9hZGVyOjphZGRSZXNw
b25zZSBkdWUgdG8gYmFkIHx0aGlzfCBwb2ludGVyPC9wPgorPHA+WW91IHNob3VsZCBzZWUgYSBm
ZXcgbWVzc2FnZXMgZm9sbG93ZWQgYnkgUEFTU0VEIG9uY2UuIDwvcD4KKzxzY3JpcHQ+CisgICAg
dmFyIGNvbnNvbGVNZXNzYWdlcyA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoInVsIik7CisgICAg
ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChjb25zb2xlTWVzc2FnZXMpOworCisgICAgaWYgKHdp
bmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikgeworCWxheW91dFRlc3RDb250cm9sbGVyLndhaXRV
bnRpbERvbmUoKTsKKwlsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7CisgICAgfQor
CisgICAgZnVuY3Rpb24gc3ViZnJhbWVMb2FkZWQoKQorICAgIHsKKwl2YXIgZnJhbWVEaXYgPSBk
b2N1bWVudC5nZXRFbGVtZW50QnlJZCgnZnJhbWVkaXYnKTsKKwlmcmFtZURpdi5pbm5lckhUTUwg
PSAnUEFTU0VEJzsKKwlpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKQorCSAgICBsYXlv
dXRUZXN0Q29udHJvbGxlci5ub3RpZnlEb25lKCk7CisgICAgfQorCisgICAgZnVuY3Rpb24gZHVt
cFJlcXVlc3RTdGF0dXMocmVxdWVzdCkKKyAgICB7CisJdHJ5IHsKKwkgICAgbG9nKCJSZWFkeSBT
dGF0ZTogIiArIHJlcXVlc3QucmVhZHlTdGF0ZSk7CisJfSBjYXRjaCAoZXgpIHsKKwkgICAgbG9n
KCJFeGNlcHRpb24gZ2V0dGluZyBzdGF0dXM6ICIgKyBleC5tZXNzYWdlKTsKKwl9CisgICAgfQor
CisgICAgZnVuY3Rpb24gbG9nKG1lc3NhZ2UpCisgICAgeworCXZhciBpdGVtID0gZG9jdW1lbnQu
Y3JlYXRlRWxlbWVudCgibGkiKTsKKwlpdGVtLmFwcGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRl
eHROb2RlKG1lc3NhZ2UpKTsKKwljb25zb2xlTWVzc2FnZXMuYXBwZW5kQ2hpbGQoaXRlbSk7Cisg
ICAgfQorPC9zY3JpcHQ+Cis8ZGl2IGlkPSJmcmFtZWRpdiI+Cis8aWZyYW1lIHNyYz0icmVzb3Vy
Y2VzL3htbGh0dHByZXF1ZXN0LWluLXVubG9hZC5odG1sIiB3aWR0aD01MCBoZWlnaHQ9MTAgYm9y
ZGVyPTA+PC9pZnJhbWU+Cis8L2Rpdj4KKzwvYm9keT4KKzwvaHRtbD4KZGlmZiAtLWdpdCBhL0xh
eW91dFRlc3RzL2h0dHAvdGVzdHMveG1saHR0cHJlcXVlc3QvcmVzb3VyY2VzL3htbGh0dHByZXF1
ZXN0LWluLXVubG9hZC5odG1sIGIvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy94bWxodHRwcmVxdWVz
dC9yZXNvdXJjZXMveG1saHR0cHJlcXVlc3QtaW4tdW5sb2FkLmh0bWwKbmV3IGZpbGUgbW9kZSAx
MDA2NDQKaW5kZXggMDAwMDAwMC4uNzJjZjQ3YwotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRl
c3RzL2h0dHAvdGVzdHMveG1saHR0cHJlcXVlc3QvcmVzb3VyY2VzL3htbGh0dHByZXF1ZXN0LWlu
LXVubG9hZC5odG1sCkBAIC0wLDAgKzEsMzYgQEAKKzxodG1sPgorPGhlYWQ+Cis8c2NyaXB0Pgor
ZnVuY3Rpb24gbG9hZFhNTCgpCit7CisgICAgdXJsID0gJ2VuZGxlc3N4bWwucGhwJzsKKworICAg
IHRyeSB7CisgICAgICAgIHhociA9IG5ldyBYTUxIdHRwUmVxdWVzdCgpOworICAgICAgICB4aHIu
b3ZlcnJpZGVNaW1lVHlwZSgndGV4dC94bWwnKTsKKyAgICAgICAgeGhyLm9ucmVhZHlzdGF0ZWNo
YW5nZSA9IHJlYWR5U3RhdGVDaGFuZ2VkOworICAgICAgICB4aHIucGFyZW50ID0gd2luZG93LnBh
cmVudDsKKyAgICAgICAgeGhyLm9wZW4oJ0dFVCcsIHVybCk7CisgICAgICAgIHhoci5vbmFib3J0
ID0gbG9hZEltYWdlOworICAgICAgICB4aHIuc2VuZChudWxsKTsKKyAgICB9IGNhdGNoIChleCkg
eworICAgICAgICB3aW5kb3cucGFyZW50LmxvZygiRXhjZXB0aW9uIGRvaW5nIFhNTEh0dHBSZXF1
ZXN0ICIrIGV4Lm1lc3NhZ2UpOworICAgIH0KK30KKworZnVuY3Rpb24gbG9hZEltYWdlKCkKK3sK
KyAgICBpbWFnZSA9IG5ldyBJbWFnZSgpOworICAgIGltYWdlLnNyYyA9ICJkYXRhOixmb28iOwor
ICAgIGRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoaW1hZ2UpOworfQorCitmdW5jdGlvbiByZWFk
eVN0YXRlQ2hhbmdlZChldnQpCit7CisgICBldnQudGFyZ2V0LnBhcmVudC5kdW1wUmVxdWVzdFN0
YXR1cyhldnQudGFyZ2V0KTsKK30KKzwvc2NyaXB0PgorPC9oZWFkPgorPGJvZHkgb25sb2FkPSJ3
aW5kb3cucGFyZW50LnN1YmZyYW1lTG9hZGVkKCkiIG9udW5sb2FkPSJsb2FkWE1MKCkiPgorPC9i
b2R5PgorPC9odG1sPgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9DaGFuZ2VMb2cgYi9XZWJDb3JlL0No
YW5nZUxvZwppbmRleCAyNDM3NjkyLi4wMjhlOWU5IDEwMDY0NAotLS0gYS9XZWJDb3JlL0NoYW5n
ZUxvZworKysgYi9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDA5LTA1LTEz
ICBEYXZpZCBMZXZpbiAgPGxldmluQGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBi
eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBCdWcgMjUzOTQ6IFJFR1JFU1NJT046IGNyYXNo
IGluIERvY3VtZW50TG9hZGVyOjphZGRSZXNwb25zZSBkdWUgdG8gYmFkIHx0aGlzfCBwb2ludGVy
CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yNTM5NAor
CisgICAgICAgIFRlc3Q6IGh0dHAvdGVzdHMveG1saHR0cHJlcXVlc3QvZnJhbWUtdW5sb2FkLWFi
b3J0LWNyYXNoLmh0bWwKKworICAgICAgICAqIGxvYWRlci9TdWJyZXNvdXJjZUxvYWRlci5jcHA6
CisgICAgICAgIChXZWJDb3JlOjpTdWJyZXNvdXJjZUxvYWRlcjo6Y3JlYXRlKToKKyAgICAgICAg
QWRkIGFub3RoZXIgY2hlY2sgdG8gc3VicmVzb3VyY2UgbG9hZGVyIHRvIGF2b2lkIGRvaW5nIGFu
eSBsb2FkcyBpbiBmcmFtZXMKKyAgICAgICAgd2hlbiB0aGUgbG9hZGVycyBhcmUgYmVpbmcgc3Rv
cHBlZC4KKwogMjAwOS0wNS0xMiAgUm9sYW5kIFN0ZWluZXIgPHJvbGFuZHN0ZWluZXJAZ29vZ2xl
LmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBFcmljIFNlaWRlbC4KZGlmZiAtLWdpdCBhL1dl
YkNvcmUvbG9hZGVyL1N1YnJlc291cmNlTG9hZGVyLmNwcCBiL1dlYkNvcmUvbG9hZGVyL1N1YnJl
c291cmNlTG9hZGVyLmNwcAppbmRleCA4MjRjODNjLi4wNDdjYzZkIDEwMDY0NAotLS0gYS9XZWJD
b3JlL2xvYWRlci9TdWJyZXNvdXJjZUxvYWRlci5jcHAKKysrIGIvV2ViQ29yZS9sb2FkZXIvU3Vi
cmVzb3VyY2VMb2FkZXIuY3BwCkBAIC02Niw3ICs2Niw3IEBAIFBhc3NSZWZQdHI8U3VicmVzb3Vy
Y2VMb2FkZXI+IFN1YnJlc291cmNlTG9hZGVyOjpjcmVhdGUoRnJhbWUqIGZyYW1lLCBTdWJyZXNv
dXJjCiAgICAgICAgIHJldHVybiAwOwogCiAgICAgRnJhbWVMb2FkZXIqIGZsID0gZnJhbWUtPmxv
YWRlcigpOwotICAgIGlmICghc2tpcENhbkxvYWRDaGVjayAmJiBmbC0+c3RhdGUoKSA9PSBGcmFt
ZVN0YXRlUHJvdmlzaW9uYWwpCisgICAgaWYgKCFza2lwQ2FuTG9hZENoZWNrICYmIChmbC0+c3Rh
dGUoKSA9PSBGcmFtZVN0YXRlUHJvdmlzaW9uYWwgfHwgZmwtPmFjdGl2ZURvY3VtZW50TG9hZGVy
KCktPmlzU3RvcHBpbmcoKSkpCiAgICAgICAgIHJldHVybiAwOwogCiAgICAgUmVzb3VyY2VSZXF1
ZXN0IG5ld1JlcXVlc3QgPSByZXF1ZXN0Owo=
</data>
<flag name="review"
          id="15233"
          type_id="1"
          status="+"
          setter="darin"
    />
          </attachment>
      

    </bug>

</bugzilla>