<?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>165675</bug_id>
          
          <creation_ts>2016-12-09 12:37:22 -0800</creation_ts>
          <short_desc>Avoid calling shrink() in the Vector destructor</short_desc>
          <delta_ts>2016-12-10 10:04:45 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Web Template Framework</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</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="Chris Dumez">cdumez</reporter>
          <assigned_to name="Chris Dumez">cdumez</assigned_to>
          <cc>andersca</cc>
    
    <cc>benjamin</cc>
    
    <cc>cmarcelo</cc>
    
    <cc>commit-queue</cc>
    
    <cc>darin</cc>
    
    <cc>dbates</cc>
    
    <cc>sam</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1258246</commentid>
    <comment_count>0</comment_count>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 12:37:22 -0800</bug_when>
    <thetext>Avoid calling shrink() in the Vector destructor to avoid function call overhead and unnecessarily reseting m_size to 0.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258247</commentid>
    <comment_count>1</comment_count>
      <attachid>296674</attachid>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 12:38:12 -0800</bug_when>
    <thetext>Created attachment 296674
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258248</commentid>
    <comment_count>2</comment_count>
      <attachid>296674</attachid>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 12:41:01 -0800</bug_when>
    <thetext>Comment on attachment 296674
Patch

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

&gt; Source/WTF/wtf/Vector.h:633
&gt;          asanSetBufferSizeToFullCapacity();

Hmm, asanSetBufferSizeToFullCapacity() seems to rely on size() :/</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258251</commentid>
    <comment_count>3</comment_count>
      <attachid>296676</attachid>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 12:44:53 -0800</bug_when>
    <thetext>Created attachment 296676
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258260</commentid>
    <comment_count>4</comment_count>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 12:55:56 -0800</bug_when>
    <thetext>How muck overhead are we talking about? Would to make sense to mark shrink() as inline or always inline?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258262</commentid>
    <comment_count>5</comment_count>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 12:58:12 -0800</bug_when>
    <thetext>Better questions, what kind of speed up (percent of PLT) can we get with this change?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258264</commentid>
    <comment_count>6</comment_count>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 12:58:32 -0800</bug_when>
    <thetext>(In reply to comment #4)
&gt; How muck overhead are we talking about? Would to make sense to mark shrink()
&gt; as inline or always inline?

Enough to show on speedometer profiles. I do not have have evidence shrink() needs to be inlined at other call sites. Also, merely inlining shrink() would still reset m_size to 0 unnecessarily in the destructor.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258265</commentid>
    <comment_count>7</comment_count>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 13:01:45 -0800</bug_when>
    <thetext>(In reply to comment #6)
&gt; (In reply to comment #4)
&gt; &gt; How muck overhead are we talking about? Would to make sense to mark shrink()
&gt; &gt; as inline or always inline?
&gt; 
&gt; Enough to show on speedometer profiles. I do not have have evidence shrink()
&gt; needs to be inlined at other call sites. Also, merely inlining shrink()
&gt; would still reset m_size to 0 unnecessarily in the destructor.

 Would it improve performance if shrink() was inlined at all callsites?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258274</commentid>
    <comment_count>8</comment_count>
      <attachid>296676</attachid>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 13:23:55 -0800</bug_when>
    <thetext>Comment on attachment 296676
Patch

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

&gt; Source/WTF/wtf/Vector.h:631
&gt; +            TypeOperations::destruct(begin(), end());

Daniel suggested offline to add a comment explaining why we don&apos;t call shrink(0), worrying that someone might undo the optimization in the future.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258277</commentid>
    <comment_count>9</comment_count>
      <attachid>296676</attachid>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 13:28:19 -0800</bug_when>
    <thetext>Comment on attachment 296676
Patch

I am surprised that function call overhead and setting m_size causes a significant performance degradation. It would nice be able to know how much of a speed up this change has or whether inlining shrink(0) everywhere would further improve performance and avoid special casing the destructor.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258285</commentid>
    <comment_count>10</comment_count>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 13:36:17 -0800</bug_when>
    <thetext>(In reply to comment #9)
&gt; [...] It would nice be able to know how much
&gt; of a speed up this change has or whether inlining shrink(0) everywhere would
&gt; further improve performance and avoid special casing the destructor.

This should read:

It would be nice to know and document how much of a speedup this change has or whether inlining shrink() everywhere would further improve performance and avoid the need to special case the logic in the destructor.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258432</commentid>
    <comment_count>11</comment_count>
      <attachid>296730</attachid>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 16:02:39 -0800</bug_when>
    <thetext>Created attachment 296730
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258442</commentid>
    <comment_count>12</comment_count>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2016-12-09 16:19:14 -0800</bug_when>
    <thetext>(In reply to comment #11)
&gt; Created attachment 296730 [details]
&gt; Patch

I think this is a bit nicer.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258463</commentid>
    <comment_count>13</comment_count>
      <attachid>296730</attachid>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 16:40:22 -0800</bug_when>
    <thetext>Comment on attachment 296730
Patch

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

&gt; Source/WTF/wtf/Vector.h:633
&gt; -            shrink(0);
&gt; +            TypeOperations::destruct(begin(), end());
&gt;  
&gt; -        asanSetBufferSizeToFullCapacity();
&gt; +        asanSetBufferSizeToFullCapacity(0);

I still suggest that we add a comment to explain that the destructor is written this way to avoid the call to shrink(0) as a performance optimization to avoid a person from undoing this change.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258573</commentid>
    <comment_count>14</comment_count>
      <attachid>296730</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2016-12-09 21:12:24 -0800</bug_when>
    <thetext>Comment on attachment 296730
Patch

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

&gt;&gt; Source/WTF/wtf/Vector.h:633
&gt;&gt; +        asanSetBufferSizeToFullCapacity(0);
&gt; 
&gt; I still suggest that we add a comment to explain that the destructor is written this way to avoid the call to shrink(0) as a performance optimization to avoid a person from undoing this change.

I’m not sure that’s needed. There are lots of different ways to write ~Vector less efficiently; I’m not sure that using shrink(0) is particularly more likely than the others. I am thinking that a comment saying “this is written the way it is as a performance optimization” is not really specific enough, and a comment saying “don’t use shrink(0) here” is too specific.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258583</commentid>
    <comment_count>15</comment_count>
    <who name="Daniel Bates">dbates</who>
    <bug_when>2016-12-09 21:29:31 -0800</bug_when>
    <thetext>(In reply to comment #14)
&gt; Comment on attachment 296730 [details]
&gt; Patch
&gt; 
&gt; View in context:
&gt; https://bugs.webkit.org/attachment.cgi?id=296730&amp;action=review
&gt; 
&gt; &gt;&gt; Source/WTF/wtf/Vector.h:633
&gt; &gt;&gt; +        asanSetBufferSizeToFullCapacity(0);
&gt; &gt; 
&gt; &gt; I still suggest that we add a comment to explain that the destructor is written this way to avoid the call to shrink(0) as a performance optimization to avoid a person from undoing this change.
&gt; 
&gt; I’m not sure that’s needed. There are lots of different ways to write
&gt; ~Vector less efficiently; I’m not sure that using shrink(0) is particularly
&gt; more likely than the others. I am thinking that a comment saying “this is
&gt; written the way it is as a performance optimization” is not really specific
&gt; enough, and a comment saying “don’t use shrink(0) here” is too specific.

Fair enough.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258699</commentid>
    <comment_count>16</comment_count>
      <attachid>296730</attachid>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2016-12-10 10:04:40 -0800</bug_when>
    <thetext>Comment on attachment 296730
Patch

Clearing flags on attachment: 296730

Committed r209664: &lt;http://trac.webkit.org/changeset/209664&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1258700</commentid>
    <comment_count>17</comment_count>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2016-12-10 10:04:45 -0800</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>296674</attachid>
            <date>2016-12-09 12:38:12 -0800</date>
            <delta_ts>2016-12-09 12:44:49 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-165675-20161209123730.patch</filename>
            <type>text/plain</type>
            <size>1172</size>
            <attacher name="Chris Dumez">cdumez</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjA5NjIwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n
ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDYzNmVhZTJhOGE0MmZjNDAwYTUxYzg0
MDlmODBhY2Q2ZmQzY2RmNTQuLjcxNTNkZTUyZTM0MWRmZjViNGU3ODc1MTVlMmYzZjk1ODU1YTE2
ZWMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh
bmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTYtMTItMDkgIENocmlzIER1bWV6ICA8Y2R1bWV6
QGFwcGxlLmNvbT4KKworICAgICAgICBBdm9pZCBjYWxsaW5nIHNocmluaygpIGluIHRoZSBWZWN0
b3IgZGVzdHJ1Y3RvcgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j
Z2k/aWQ9MTY1Njc1CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg
ICAgICAgQXZvaWQgY2FsbGluZyBzaHJpbmsoKSBpbiB0aGUgVmVjdG9yIGRlc3RydWN0b3IgdG8g
YXZvaWQgZnVuY3Rpb24gY2FsbAorICAgICAgICBvdmVyaGVhZCBhbmQgdW5uZWNlc3NhcmlseSBy
ZXNldGluZyBtX3NpemUgdG8gMC4KKworICAgICAgICAqIHd0Zi9WZWN0b3IuaDoKKyAgICAgICAg
KFdURjo6VmVjdG9yOjp+VmVjdG9yKToKKwogMjAxNi0xMi0wOSAgR2VvZmZyZXkgR2FyZW4gIDxn
Z2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIE1vdmVkIE9yZGluYWxOdW1iZXIgaW50byBpdHMg
b3duIGZpbGUKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL1ZlY3Rvci5oIGIvU291cmNlL1dU
Ri93dGYvVmVjdG9yLmgKaW5kZXggNDliNDY5ODgxYzEyM2M1OTNmNTg0NjE4YmQ0NDE3NWY1NGQ1
MDQ2Yi4uZmNlZjZiMWY4ZjY1MDk4ODkyMGNkMTYwMzRkMGQ5MWQyNDBkMzI0NSAxMDA2NDQKLS0t
IGEvU291cmNlL1dURi93dGYvVmVjdG9yLmgKKysrIGIvU291cmNlL1dURi93dGYvVmVjdG9yLmgK
QEAgLTYyOCw3ICs2MjgsNyBAQCBwdWJsaWM6CiAgICAgflZlY3RvcigpCiAgICAgewogICAgICAg
ICBpZiAobV9zaXplKQotICAgICAgICAgICAgc2hyaW5rKDApOworICAgICAgICAgICAgVHlwZU9w
ZXJhdGlvbnM6OmRlc3RydWN0KGJlZ2luKCksIGVuZCgpKTsKIAogICAgICAgICBhc2FuU2V0QnVm
ZmVyU2l6ZVRvRnVsbENhcGFjaXR5KCk7CiAgICAgfQo=
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>296676</attachid>
            <date>2016-12-09 12:44:53 -0800</date>
            <delta_ts>2016-12-09 16:02:34 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-165675-20161209124411.patch</filename>
            <type>text/plain</type>
            <size>1262</size>
            <attacher name="Chris Dumez">cdumez</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjA5NjIwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n
ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDYzNmVhZTJhOGE0MmZjNDAwYTUxYzg0
MDlmODBhY2Q2ZmQzY2RmNTQuLjcxNTNkZTUyZTM0MWRmZjViNGU3ODc1MTVlMmYzZjk1ODU1YTE2
ZWMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh
bmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTYtMTItMDkgIENocmlzIER1bWV6ICA8Y2R1bWV6
QGFwcGxlLmNvbT4KKworICAgICAgICBBdm9pZCBjYWxsaW5nIHNocmluaygpIGluIHRoZSBWZWN0
b3IgZGVzdHJ1Y3RvcgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j
Z2k/aWQ9MTY1Njc1CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg
ICAgICAgQXZvaWQgY2FsbGluZyBzaHJpbmsoKSBpbiB0aGUgVmVjdG9yIGRlc3RydWN0b3IgdG8g
YXZvaWQgZnVuY3Rpb24gY2FsbAorICAgICAgICBvdmVyaGVhZCBhbmQgdW5uZWNlc3NhcmlseSBy
ZXNldGluZyBtX3NpemUgdG8gMC4KKworICAgICAgICAqIHd0Zi9WZWN0b3IuaDoKKyAgICAgICAg
KFdURjo6VmVjdG9yOjp+VmVjdG9yKToKKwogMjAxNi0xMi0wOSAgR2VvZmZyZXkgR2FyZW4gIDxn
Z2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIE1vdmVkIE9yZGluYWxOdW1iZXIgaW50byBpdHMg
b3duIGZpbGUKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL1ZlY3Rvci5oIGIvU291cmNlL1dU
Ri93dGYvVmVjdG9yLmgKaW5kZXggNDliNDY5ODgxYzEyM2M1OTNmNTg0NjE4YmQ0NDE3NWY1NGQ1
MDQ2Yi4uNDU5Y2NkMjRhNTViN2YwNjc3NGVkMjQyZGM3YjUyZGFlMmIxZWZkZiAxMDA2NDQKLS0t
IGEvU291cmNlL1dURi93dGYvVmVjdG9yLmgKKysrIGIvU291cmNlL1dURi93dGYvVmVjdG9yLmgK
QEAgLTYyNyw5ICs2MjcsMTIgQEAgcHVibGljOgogCiAgICAgflZlY3RvcigpCiAgICAgewotICAg
ICAgICBpZiAobV9zaXplKQotICAgICAgICAgICAgc2hyaW5rKDApOwotCisgICAgICAgIGlmICht
X3NpemUpIHsKKyAgICAgICAgICAgIFR5cGVPcGVyYXRpb25zOjpkZXN0cnVjdChiZWdpbigpLCBl
bmQoKSk7CisjaWYgQVNBTl9FTkFCTEVECisgICAgICAgICAgICBtX3NpemUgPSAwOworI2VuZGlm
CisgICAgICAgIH0KICAgICAgICAgYXNhblNldEJ1ZmZlclNpemVUb0Z1bGxDYXBhY2l0eSgpOwog
ICAgIH0KIAo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>296730</attachid>
            <date>2016-12-09 16:02:39 -0800</date>
            <delta_ts>2016-12-10 10:04:40 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-165675-20161209160156.patch</filename>
            <type>text/plain</type>
            <size>2616</size>
            <attacher name="Chris Dumez">cdumez</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjA5NjI0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n
ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDYzNmVhZTJhOGE0MmZjNDAwYTUxYzg0
MDlmODBhY2Q2ZmQzY2RmNTQuLjdmMWFiMDNlYTY1MzE0NjI3N2RkYjQ0YzNhOTQwNjJlYzNjMGVk
MTQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh
bmdlTG9nCkBAIC0xLDMgKzEsMTggQEAKKzIwMTYtMTItMDkgIENocmlzIER1bWV6ICA8Y2R1bWV6
QGFwcGxlLmNvbT4KKworICAgICAgICBBdm9pZCBjYWxsaW5nIHNocmluaygpIGluIHRoZSBWZWN0
b3IgZGVzdHJ1Y3RvcgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j
Z2k/aWQ9MTY1Njc1CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg
ICAgICAgQXZvaWQgY2FsbGluZyBzaHJpbmsoKSBpbiB0aGUgVmVjdG9yIGRlc3RydWN0b3IgdG8g
YXZvaWQgZnVuY3Rpb24gY2FsbAorICAgICAgICBvdmVyaGVhZCBhbmQgdW5uZWNlc3NhcmlseSBy
ZXNldGluZyBtX3NpemUgdG8gMC4KKworICAgICAgICAqIHd0Zi9WZWN0b3IuaDoKKyAgICAgICAg
KFdURjo6VmVjdG9yOjp+VmVjdG9yKToKKyAgICAgICAgKFdURjo6VmVjdG9yOjphc2FuU2V0QnVm
ZmVyU2l6ZVRvRnVsbENhcGFjaXR5KToKKyAgICAgICAgKFdURjo6bWluQ2FwYWNpdHk+Ojphc2Fu
U2V0QnVmZmVyU2l6ZVRvRnVsbENhcGFjaXR5KToKKwogMjAxNi0xMi0wOSAgR2VvZmZyZXkgR2Fy
ZW4gIDxnZ2FyZW5AYXBwbGUuY29tPgogCiAgICAgICAgIE1vdmVkIE9yZGluYWxOdW1iZXIgaW50
byBpdHMgb3duIGZpbGUKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL1ZlY3Rvci5oIGIvU291
cmNlL1dURi93dGYvVmVjdG9yLmgKaW5kZXggNDliNDY5ODgxYzEyM2M1OTNmNTg0NjE4YmQ0NDE3
NWY1NGQ1MDQ2Yi4uNmZkZDE5YWQ0OTVjM2Y2MDc2ZDI3MjAwZjRhZjg0OTNjYmEyNDM1MyAxMDA2
NDQKLS0tIGEvU291cmNlL1dURi93dGYvVmVjdG9yLmgKKysrIGIvU291cmNlL1dURi93dGYvVmVj
dG9yLmgKQEAgLTYyOCw5ICs2MjgsOSBAQCBwdWJsaWM6CiAgICAgflZlY3RvcigpCiAgICAgewog
ICAgICAgICBpZiAobV9zaXplKQotICAgICAgICAgICAgc2hyaW5rKDApOworICAgICAgICAgICAg
VHlwZU9wZXJhdGlvbnM6OmRlc3RydWN0KGJlZ2luKCksIGVuZCgpKTsKIAotICAgICAgICBhc2Fu
U2V0QnVmZmVyU2l6ZVRvRnVsbENhcGFjaXR5KCk7CisgICAgICAgIGFzYW5TZXRCdWZmZXJTaXpl
VG9GdWxsQ2FwYWNpdHkoMCk7CiAgICAgfQogCiAgICAgVmVjdG9yKGNvbnN0IFZlY3RvciYpOwpA
QCAtNzg5LDcgKzc4OSw5IEBAIHByaXZhdGU6CiAgICAgdGVtcGxhdGU8dHlwZW5hbWUuLi4gQXJn
cz4gYm9vbCB0cnlDb25zdHJ1Y3RBbmRBcHBlbmRTbG93Q2FzZShBcmdzJiYuLi4pOwogCiAgICAg
dm9pZCBhc2FuU2V0SW5pdGlhbEJ1ZmZlclNpemVUbyhzaXplX3QpOwotICAgIHZvaWQgYXNhblNl
dEJ1ZmZlclNpemVUb0Z1bGxDYXBhY2l0eSgpOworICAgIHZvaWQgYXNhblNldEJ1ZmZlclNpemVU
b0Z1bGxDYXBhY2l0eShzaXplX3QpOworICAgIHZvaWQgYXNhblNldEJ1ZmZlclNpemVUb0Z1bGxD
YXBhY2l0eSgpIHsgYXNhblNldEJ1ZmZlclNpemVUb0Z1bGxDYXBhY2l0eShzaXplKCkpOyB9CisK
ICAgICB2b2lkIGFzYW5CdWZmZXJTaXplV2lsbENoYW5nZVRvKHNpemVfdCk7CiAKICAgICB1c2lu
ZyBCYXNlOjptX3NpemU7CkBAIC0xMDU2LDE0ICsxMDU4LDE2IEBAIGlubGluZSB2b2lkIFZlY3Rv
cjxULCBpbmxpbmVDYXBhY2l0eSwgT3ZlcmZsb3dIYW5kbGVyLCBtaW5DYXBhY2l0eT46OmFzYW5T
ZXRJbml0CiB9CiAKIHRlbXBsYXRlPHR5cGVuYW1lIFQsIHNpemVfdCBpbmxpbmVDYXBhY2l0eSwg
dHlwZW5hbWUgT3ZlcmZsb3dIYW5kbGVyLCBzaXplX3QgbWluQ2FwYWNpdHk+Ci1pbmxpbmUgdm9p
ZCBWZWN0b3I8VCwgaW5saW5lQ2FwYWNpdHksIE92ZXJmbG93SGFuZGxlciwgbWluQ2FwYWNpdHk+
Ojphc2FuU2V0QnVmZmVyU2l6ZVRvRnVsbENhcGFjaXR5KCkKK2lubGluZSB2b2lkIFZlY3RvcjxU
LCBpbmxpbmVDYXBhY2l0eSwgT3ZlcmZsb3dIYW5kbGVyLCBtaW5DYXBhY2l0eT46OmFzYW5TZXRC
dWZmZXJTaXplVG9GdWxsQ2FwYWNpdHkoc2l6ZV90IHNpemUpCiB7CiAjaWYgQVNBTl9FTkFCTEVE
CiAgICAgaWYgKCFidWZmZXIoKSkKICAgICAgICAgcmV0dXJuOwogCiAgICAgLy8gQVNhbiByZXF1
aXJlcyB0aGF0IHRoZSBhbm5vdGF0aW9uIGlzIHJldHVybmVkIHRvIGl0cyBpbml0aWFsIHN0YXRl
IGJlZm9yZSBkZWFsbG9jYXRpb24uCi0gICAgX19zYW5pdGl6ZXJfYW5ub3RhdGVfY29udGlndW91
c19jb250YWluZXIoYnVmZmVyKCksIGVuZE9mQnVmZmVyKCksIGJ1ZmZlcigpICsgc2l6ZSgpLCBl
bmRPZkJ1ZmZlcigpKTsKKyAgICBfX3Nhbml0aXplcl9hbm5vdGF0ZV9jb250aWd1b3VzX2NvbnRh
aW5lcihidWZmZXIoKSwgZW5kT2ZCdWZmZXIoKSwgYnVmZmVyKCkgKyBzaXplLCBlbmRPZkJ1ZmZl
cigpKTsKKyNlbHNlCisgICAgVU5VU0VEX1BBUkFNKHNpemUpOwogI2VuZGlmCiB9CiAK
</data>

          </attachment>
      

    </bug>

</bugzilla>