<?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>84970</bug_id>
          
          <creation_ts>2012-04-26 09:17:51 -0700</creation_ts>
          <short_desc>Mutex failure when HashTable is memcpy&apos;ed in debug build</short_desc>
          <delta_ts>2012-06-06 08:23:53 -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>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>P3</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Yong Li">yong.li.webkit</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>joenotcharles</cc>
    
    <cc>levin+threading</cc>
    
    <cc>mario</cc>
    
    <cc>webkit.review.bot</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>610675</commentid>
    <comment_count>0</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 09:17:51 -0700</bug_when>
    <thetext>In debug build, HashTable contains a mutex object. But Mutex isn&apos;t copyable on many platforms. However, JS Parser can potentially memcpy/memmove HashTable objects in its Vector&lt;Scope&gt;. When that happens, pthread_mutex_destroy can fail.

Probably we should change the way how Parser manages the scope vector (how about a linked list?).

For now, I&apos;m going to make HashTable use OwnPtr&lt;Mutex&gt; for CHECK_HASHTABLE_ITERATORS, and assert the results of pthread_mutex_int() and pthread_mutex_destroy().</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610713</commentid>
    <comment_count>1</comment_count>
      <attachid>139023</attachid>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 10:27:41 -0700</bug_when>
    <thetext>Created attachment 139023
the patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610722</commentid>
    <comment_count>2</comment_count>
    <who name="Joe Mason">joenotcharles</who>
    <bug_when>2012-04-26 10:43:23 -0700</bug_when>
    <thetext>I notice that Mutex has WTF_MAKE_NONCOPYABLE, which is bypassed by memcpy/memmove.  Is there any way to assert in Vector&lt;Scope&gt; when a noncopyable object is added?  Preferably at compile time?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610724</commentid>
    <comment_count>3</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 10:45:13 -0700</bug_when>
    <thetext>(In reply to comment #2)
&gt; I notice that Mutex has WTF_MAKE_NONCOPYABLE, which is bypassed by memcpy/memmove.  Is there any way to assert in Vector&lt;Scope&gt; when a noncopyable object is added?  Preferably at compile time?

HashTable has copy ctor and operator= implemented, so it is copyable (mutex is not copied though)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610728</commentid>
    <comment_count>4</comment_count>
      <attachid>139023</attachid>
    <who name="Build Bot">buildbot</who>
    <bug_when>2012-04-26 10:51:21 -0700</bug_when>
    <thetext>Comment on attachment 139023
the patch

Attachment 139023 did not pass win-ews (win):
Output: http://queues.webkit.org/results/12517992</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610732</commentid>
    <comment_count>5</comment_count>
    <who name="Joe Mason">joenotcharles</who>
    <bug_when>2012-04-26 10:54:03 -0700</bug_when>
    <thetext>(In reply to comment #3)
&gt; (In reply to comment #2)
&gt; &gt; I notice that Mutex has WTF_MAKE_NONCOPYABLE, which is bypassed by memcpy/memmove.  Is there any way to assert in Vector&lt;Scope&gt; when a noncopyable object is added?  Preferably at compile time?
&gt; 
&gt; HashTable has copy ctor and operator= implemented, so it is copyable (mutex is not copied though)

Yeah, that would make it much harder to detect.  Have you looked for other classes which may have this problem?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610888</commentid>
    <comment_count>6</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2012-04-26 13:21:27 -0700</bug_when>
    <thetext>&gt; Mutex isn&apos;t copyable on many platforms.

Are you saying that it&apos;s not movable with memcpy? Why does the problem occur?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610908</commentid>
    <comment_count>7</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 13:34:25 -0700</bug_when>
    <thetext>(In reply to comment #6)
&gt; &gt; Mutex isn&apos;t copyable on many platforms.
&gt; 
&gt; Are you saying that it&apos;s not movable with memcpy? Why does the problem occur?

The behavior of using a copied mutex is undefined. (CRITICAL_SECTION on Windows is not copyable, too). The addresses of mutexes are critical, and can be used by system to identify them.

http://linux.die.net/man/3/pthread_mutex_init

&quot;Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined.&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610915</commentid>
    <comment_count>8</comment_count>
      <attachid>139060</attachid>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 13:37:14 -0700</bug_when>
    <thetext>Created attachment 139060
fix the build error</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610931</commentid>
    <comment_count>9</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2012-04-26 13:47:53 -0700</bug_when>
    <thetext>(In reply to comment #5)
&gt; (In reply to comment #3)
&gt; &gt; (In reply to comment #2)
&gt; &gt; &gt; I notice that Mutex has WTF_MAKE_NONCOPYABLE, which is bypassed by memcpy/memmove.  Is there any way to assert in Vector&lt;Scope&gt; when a noncopyable object is added?  Preferably at compile time?
&gt; &gt; 
&gt; &gt; HashTable has copy ctor and operator= implemented, so it is copyable (mutex is not copied though)
&gt; 
&gt; Yeah, that would make it much harder to detect.  Have you looked for other classes which may have this problem?

Not yet. The wild thing is JSC::Parser can memcpy HashSet, which is not very usual. The assert added for pthread_mutex_destroy could help detect similar issues.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>610952</commentid>
    <comment_count>10</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2012-04-26 14:01:44 -0700</bug_when>
    <thetext>Thank you for the explanation.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>615340</commentid>
    <comment_count>11</comment_count>
      <attachid>139060</attachid>
    <who name="Rob Buis">rwlbuis</who>
    <bug_when>2012-05-03 09:27:53 -0700</bug_when>
    <thetext>Comment on attachment 139060
fix the build error

Looks good.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>615382</commentid>
    <comment_count>12</comment_count>
      <attachid>139060</attachid>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-05-03 10:17:24 -0700</bug_when>
    <thetext>Comment on attachment 139060
fix the build error

Clearing flags on attachment: 139060

Committed r115988: &lt;http://trac.webkit.org/changeset/115988&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>615383</commentid>
    <comment_count>13</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-05-03 10:17:30 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>642492</commentid>
    <comment_count>14</comment_count>
    <who name="Mario Sanchez Prada">mario</who>
    <bug_when>2012-06-06 08:23:53 -0700</bug_when>
    <thetext>This patch has caused the GTK 64bit Debug bot to fail for a while already [1], with the following error:

*** glibc detected *** /home/slave/webkitgtk/gtk-linux-64-debug/build/Tools/gtk/../Scripts/../../WebKitBuild/Debug/Programs/TestWebKitAPI/WTF/TestHashMap: malloc(): memory corruption: 0x000000000067fdf0 ***

I&apos;ve investigated a bit the issue and localized the source of this problem in this patch, specifically in the changes done in HashTable.h.

I will try to come up with a solution for this, but will appreciate any hint on this in case you have any.

Here&apos;s a new bug for tracking down this issue: https://bugs.webkit.org/show_bug.cgi?id=88419

Thanks,
Mario

[1] http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug/builds/33848/steps/API%20tests/logs/stdio</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>139023</attachid>
            <date>2012-04-26 10:27:41 -0700</date>
            <delta_ts>2012-04-26 13:36:06 -0700</delta_ts>
            <desc>the patch</desc>
            <filename>84970.patch</filename>
            <type>text/plain</type>
            <size>4022</size>
            <attacher name="Yong Li">yong.li.webkit</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cK
aW5kZXggMDBhN2VhNS4uODI4MjY1NSAxMDA2NDQKLS0tIGEvU291cmNlL1dURi9DaGFuZ2VMb2cK
KysrIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyNCBAQAorMjAxMi0wNC0yNiAg
WW9uZyBMaSAgPHlvbGlAcmltLmNvbT4KKworICAgICAgICBNdXRleCBmYWlsdXJlIHdoZW4gSGFz
aFRhYmxlIGlzIG1lbW9yeSBtb3ZlZCBpbiBkZWJ1ZyBidWlsZAorICAgICAgICBodHRwczovL2J1
Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODQ5NzAKKworICAgICAgICBSZXZpZXdlZCBi
eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAxLiBSZXBsYWNlIG1fbXV0ZXggd2l0aCBPd25Q
dHI8bV9tdXRleD4gc28gSGFzaFRhYmxlIGlzIHN0aWxsCisgICAgICAgICAgIG1lbW9yeSBtb3Zh
YmxlIGluIGRlYnVnIGJ1aWxkLgorICAgICAgICAyLiBBc3NlcnQgc3VjY2Vzc2VzIG9mIHB0aHJl
YWRfbXV0ZXhfaW5pdCgpIGFuZCBwdGhyZWFkX211dGV4X2Rlc3Ryb3koKS4KKworICAgICAgICAq
IHd0Zi9IYXNoVGFibGUuaDoKKyAgICAgICAgKEhhc2hUYWJsZSk6CisgICAgICAgIChXVEY6Ojo6
SGFzaFRhYmxlKToKKyAgICAgICAgKFdURjo6OjppbnZhbGlkYXRlSXRlcmF0b3JzKToKKyAgICAg
ICAgKFdURjo6YWRkSXRlcmF0b3IpOgorICAgICAgICAoV1RGOjpyZW1vdmVJdGVyYXRvcik6Cisg
ICAgICAgICogd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6
Ok11dGV4KToKKyAgICAgICAgKFdURjo6TXV0ZXg6On5NdXRleCk6CisKIDIwMTItMDQtMjUgIEJl
bmphbWluIFBvdWxhaW4gIDxiZW5qYW1pbkB3ZWJraXQub3JnPgogCiAgICAgICAgIEFkZCBhIHZl
cnNpb24gb2YgU3RyaW5nSW1wbDo6ZmluZCgpIHdpdGhvdXQgb2Zmc2V0CmRpZmYgLS1naXQgYS9T
b3VyY2UvV1RGL3d0Zi9IYXNoVGFibGUuaCBiL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJsZS5oCmlu
ZGV4IDA2ZmVlZDYuLmJiODk1MWEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJs
ZS5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJsZS5oCkBAIC0zMCw2ICszMCwxMiBAQAog
I2luY2x1ZGUgPHd0Zi9UaHJlYWRpbmcuaD4KICNpbmNsdWRlIDx3dGYvVmFsdWVDaGVjay5oPgog
CisjaWZkZWYgTkRFQlVHCisvLyBSZXF1aXJlZCBmb3IgQ0hFQ0tfSEFTSFRBQkxFX0lURVJBVE9S
Uy4KKyNpbmNsdWRlIDx3dGYvT3duUHRyLmg+CisjaW5jbHVkZSA8d3RmL1Bhc3NPd25QdHIuaD4K
KyNlbmRpZgorCiBuYW1lc3BhY2UgV1RGIHsKIAogI2RlZmluZSBEVU1QX0hBU0hUQUJMRV9TVEFU
UyAwCkBAIC00NDEsNyArNDQ3LDggQEAgbmFtZXNwYWNlIFdURiB7CiAgICAgcHVibGljOgogICAg
ICAgICAvLyBBbGwgYWNjZXNzIHRvIG1faXRlcmF0b3JzIHNob3VsZCBiZSBndWFyZGVkIHdpdGgg
bV9tdXRleC4KICAgICAgICAgbXV0YWJsZSBjb25zdF9pdGVyYXRvciogbV9pdGVyYXRvcnM7Ci0g
ICAgICAgIG11dGFibGUgTXV0ZXggbV9tdXRleDsKKyAgICAgICAgLy8gVXNlIE93blB0ciBzbyBI
YXNoVGFibGUgY2FuIHN0aWxsIGJlIG1lbW1vdmUnZCBvciBtZW1jcHknZWQuCisgICAgICAgIG11
dGFibGUgT3duUHRyPE11dGV4PiBtX211dGV4OwogI2VuZGlmCiAgICAgfTsKIApAQCAtNDU0LDYg
KzQ2MSw3IEBAIG5hbWVzcGFjZSBXVEYgewogICAgICAgICAsIG1fZGVsZXRlZENvdW50KDApCiAj
aWYgQ0hFQ0tfSEFTSFRBQkxFX0lURVJBVE9SUwogICAgICAgICAsIG1faXRlcmF0b3JzKDApCisg
ICAgICAgICwgbV9tdXRleChhZG9wdFB0cihuZXcgTXV0ZXgpKQogI2VuZGlmCiAgICAgewogICAg
IH0KQEAgLTEwMDYsNiArMTAxNCw3IEBAIG5hbWVzcGFjZSBXVEYgewogICAgICAgICAsIG1fZGVs
ZXRlZENvdW50KDApCiAjaWYgQ0hFQ0tfSEFTSFRBQkxFX0lURVJBVE9SUwogICAgICAgICAsIG1f
aXRlcmF0b3JzKDApCisgICAgICAgICwgbV9tdXRleChhZG9wdFB0cihuZXcgTXV0ZXgpKQogI2Vu
ZGlmCiAgICAgewogICAgICAgICAvLyBDb3B5IHRoZSBoYXNoIHRhYmxlIHRoZSBkdW1iIHdheSwg
YnkgYWRkaW5nIGVhY2ggZWxlbWVudCB0byB0aGUgbmV3IHRhYmxlLgpAQCAtMTA5OSw3ICsxMTA4
LDcgQEAgbmFtZXNwYWNlIFdURiB7CiAgICAgdGVtcGxhdGU8dHlwZW5hbWUgS2V5LCB0eXBlbmFt
ZSBWYWx1ZSwgdHlwZW5hbWUgRXh0cmFjdG9yLCB0eXBlbmFtZSBIYXNoRnVuY3Rpb25zLCB0eXBl
bmFtZSBUcmFpdHMsIHR5cGVuYW1lIEtleVRyYWl0cz4KICAgICB2b2lkIEhhc2hUYWJsZTxLZXks
IFZhbHVlLCBFeHRyYWN0b3IsIEhhc2hGdW5jdGlvbnMsIFRyYWl0cywgS2V5VHJhaXRzPjo6aW52
YWxpZGF0ZUl0ZXJhdG9ycygpCiAgICAgewotICAgICAgICBNdXRleExvY2tlciBsb2NrKG1fbXV0
ZXgpOworICAgICAgICBNdXRleExvY2tlciBsb2NrKCptX211dGV4KTsKICAgICAgICAgY29uc3Rf
aXRlcmF0b3IqIG5leHQ7CiAgICAgICAgIGZvciAoY29uc3RfaXRlcmF0b3IqIHAgPSBtX2l0ZXJh
dG9yczsgcDsgcCA9IG5leHQpIHsKICAgICAgICAgICAgIG5leHQgPSBwLT5tX25leHQ7CkBAIC0x
MTIxLDcgKzExMzAsNyBAQCBuYW1lc3BhY2UgV1RGIHsKICAgICAgICAgaWYgKCF0YWJsZSkgewog
ICAgICAgICAgICAgaXQtPm1fbmV4dCA9IDA7CiAgICAgICAgIH0gZWxzZSB7Ci0gICAgICAgICAg
ICBNdXRleExvY2tlciBsb2NrKHRhYmxlLT5tX211dGV4KTsKKyAgICAgICAgICAgIE11dGV4TG9j
a2VyIGxvY2soKnRhYmxlLT5tX211dGV4KTsKICAgICAgICAgICAgIEFTU0VSVCh0YWJsZS0+bV9p
dGVyYXRvcnMgIT0gaXQpOwogICAgICAgICAgICAgaXQtPm1fbmV4dCA9IHRhYmxlLT5tX2l0ZXJh
dG9yczsKICAgICAgICAgICAgIHRhYmxlLT5tX2l0ZXJhdG9ycyA9IGl0OwpAQCAtMTE0Myw3ICsx
MTUyLDcgQEAgbmFtZXNwYWNlIFdURiB7CiAgICAgICAgICAgICBBU1NFUlQoIWl0LT5tX25leHQp
OwogICAgICAgICAgICAgQVNTRVJUKCFpdC0+bV9wcmV2aW91cyk7CiAgICAgICAgIH0gZWxzZSB7
Ci0gICAgICAgICAgICBNdXRleExvY2tlciBsb2NrKGl0LT5tX3RhYmxlLT5tX211dGV4KTsKKyAg
ICAgICAgICAgIE11dGV4TG9ja2VyIGxvY2soKml0LT5tX3RhYmxlLT5tX211dGV4KTsKICAgICAg
ICAgICAgIGlmIChpdC0+bV9uZXh0KSB7CiAgICAgICAgICAgICAgICAgQVNTRVJUKGl0LT5tX25l
eHQtPm1fcHJldmlvdXMgPT0gaXQpOwogICAgICAgICAgICAgICAgIGl0LT5tX25leHQtPm1fcHJl
dmlvdXMgPSBpdC0+bV9wcmV2aW91czsKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL1RocmVh
ZGluZ1B0aHJlYWRzLmNwcCBiL1NvdXJjZS9XVEYvd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcApp
bmRleCBhYmQzNTBkLi5mNTdmMzIyIDEwMDY0NAotLS0gYS9Tb3VyY2UvV1RGL3d0Zi9UaHJlYWRp
bmdQdGhyZWFkcy5jcHAKKysrIGIvU291cmNlL1dURi93dGYvVGhyZWFkaW5nUHRocmVhZHMuY3Bw
CkBAIC0yODgsMTQgKzI4OCwxNiBAQCBNdXRleDo6TXV0ZXgoKQogICAgIHB0aHJlYWRfbXV0ZXhh
dHRyX2luaXQoJmF0dHIpOwogICAgIHB0aHJlYWRfbXV0ZXhhdHRyX3NldHR5cGUoJmF0dHIsIFBU
SFJFQURfTVVURVhfTk9STUFMKTsKIAotICAgIHB0aHJlYWRfbXV0ZXhfaW5pdCgmbV9tdXRleCwg
JmF0dHIpOworICAgIGludCByZXN1bHQgPSBwdGhyZWFkX211dGV4X2luaXQoJm1fbXV0ZXgsICZh
dHRyKTsKKyAgICBBU1NFUlRfVU5VU0VEKHJlc3VsdCwgIXJlc3VsdCk7CiAKICAgICBwdGhyZWFk
X211dGV4YXR0cl9kZXN0cm95KCZhdHRyKTsKIH0KIAogTXV0ZXg6On5NdXRleCgpCiB7Ci0gICAg
cHRocmVhZF9tdXRleF9kZXN0cm95KCZtX211dGV4KTsKKyAgICBpbnQgcmVzdWx0ID0gcHRocmVh
ZF9tdXRleF9kZXN0cm95KCZtX211dGV4KTsKKyAgICBBU1NFUlRfVU5VU0VEKHJlc3VsdCwgIXJl
c3VsdCk7CiB9CiAKIHZvaWQgTXV0ZXg6OmxvY2soKQo=
</data>
<flag name="commit-queue"
          id="144564"
          type_id="3"
          status="-"
          setter="buildbot"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>139060</attachid>
            <date>2012-04-26 13:37:14 -0700</date>
            <delta_ts>2012-05-03 10:17:24 -0700</delta_ts>
            <desc>fix the build error</desc>
            <filename>84970.patch</filename>
            <type>text/plain</type>
            <size>4023</size>
            <attacher name="Yong Li">yong.li.webkit</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cK
aW5kZXggMDBhN2VhNS4uODI4MjY1NSAxMDA2NDQKLS0tIGEvU291cmNlL1dURi9DaGFuZ2VMb2cK
KysrIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyNCBAQAorMjAxMi0wNC0yNiAg
WW9uZyBMaSAgPHlvbGlAcmltLmNvbT4KKworICAgICAgICBNdXRleCBmYWlsdXJlIHdoZW4gSGFz
aFRhYmxlIGlzIG1lbW9yeSBtb3ZlZCBpbiBkZWJ1ZyBidWlsZAorICAgICAgICBodHRwczovL2J1
Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODQ5NzAKKworICAgICAgICBSZXZpZXdlZCBi
eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAxLiBSZXBsYWNlIG1fbXV0ZXggd2l0aCBPd25Q
dHI8bV9tdXRleD4gc28gSGFzaFRhYmxlIGlzIHN0aWxsCisgICAgICAgICAgIG1lbW9yeSBtb3Zh
YmxlIGluIGRlYnVnIGJ1aWxkLgorICAgICAgICAyLiBBc3NlcnQgc3VjY2Vzc2VzIG9mIHB0aHJl
YWRfbXV0ZXhfaW5pdCgpIGFuZCBwdGhyZWFkX211dGV4X2Rlc3Ryb3koKS4KKworICAgICAgICAq
IHd0Zi9IYXNoVGFibGUuaDoKKyAgICAgICAgKEhhc2hUYWJsZSk6CisgICAgICAgIChXVEY6Ojo6
SGFzaFRhYmxlKToKKyAgICAgICAgKFdURjo6OjppbnZhbGlkYXRlSXRlcmF0b3JzKToKKyAgICAg
ICAgKFdURjo6YWRkSXRlcmF0b3IpOgorICAgICAgICAoV1RGOjpyZW1vdmVJdGVyYXRvcik6Cisg
ICAgICAgICogd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNwcDoKKyAgICAgICAgKFdURjo6TXV0ZXg6
Ok11dGV4KToKKyAgICAgICAgKFdURjo6TXV0ZXg6On5NdXRleCk6CisKIDIwMTItMDQtMjUgIEJl
bmphbWluIFBvdWxhaW4gIDxiZW5qYW1pbkB3ZWJraXQub3JnPgogCiAgICAgICAgIEFkZCBhIHZl
cnNpb24gb2YgU3RyaW5nSW1wbDo6ZmluZCgpIHdpdGhvdXQgb2Zmc2V0CmRpZmYgLS1naXQgYS9T
b3VyY2UvV1RGL3d0Zi9IYXNoVGFibGUuaCBiL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJsZS5oCmlu
ZGV4IDA2ZmVlZDYuLmJiODk1MWEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJs
ZS5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL0hhc2hUYWJsZS5oCkBAIC0zMCw2ICszMCwxMiBAQAog
I2luY2x1ZGUgPHd0Zi9UaHJlYWRpbmcuaD4KICNpbmNsdWRlIDx3dGYvVmFsdWVDaGVjay5oPgog
CisjaWZuZGVmIE5ERUJVRworLy8gUmVxdWlyZWQgZm9yIENIRUNLX0hBU0hUQUJMRV9JVEVSQVRP
UlMuCisjaW5jbHVkZSA8d3RmL093blB0ci5oPgorI2luY2x1ZGUgPHd0Zi9QYXNzT3duUHRyLmg+
CisjZW5kaWYKKwogbmFtZXNwYWNlIFdURiB7CiAKICNkZWZpbmUgRFVNUF9IQVNIVEFCTEVfU1RB
VFMgMApAQCAtNDQxLDcgKzQ0Nyw4IEBAIG5hbWVzcGFjZSBXVEYgewogICAgIHB1YmxpYzoKICAg
ICAgICAgLy8gQWxsIGFjY2VzcyB0byBtX2l0ZXJhdG9ycyBzaG91bGQgYmUgZ3VhcmRlZCB3aXRo
IG1fbXV0ZXguCiAgICAgICAgIG11dGFibGUgY29uc3RfaXRlcmF0b3IqIG1faXRlcmF0b3JzOwot
ICAgICAgICBtdXRhYmxlIE11dGV4IG1fbXV0ZXg7CisgICAgICAgIC8vIFVzZSBPd25QdHIgc28g
SGFzaFRhYmxlIGNhbiBzdGlsbCBiZSBtZW1tb3ZlJ2Qgb3IgbWVtY3B5J2VkLgorICAgICAgICBt
dXRhYmxlIE93blB0cjxNdXRleD4gbV9tdXRleDsKICNlbmRpZgogICAgIH07CiAKQEAgLTQ1NCw2
ICs0NjEsNyBAQCBuYW1lc3BhY2UgV1RGIHsKICAgICAgICAgLCBtX2RlbGV0ZWRDb3VudCgwKQog
I2lmIENIRUNLX0hBU0hUQUJMRV9JVEVSQVRPUlMKICAgICAgICAgLCBtX2l0ZXJhdG9ycygwKQor
ICAgICAgICAsIG1fbXV0ZXgoYWRvcHRQdHIobmV3IE11dGV4KSkKICNlbmRpZgogICAgIHsKICAg
ICB9CkBAIC0xMDA2LDYgKzEwMTQsNyBAQCBuYW1lc3BhY2UgV1RGIHsKICAgICAgICAgLCBtX2Rl
bGV0ZWRDb3VudCgwKQogI2lmIENIRUNLX0hBU0hUQUJMRV9JVEVSQVRPUlMKICAgICAgICAgLCBt
X2l0ZXJhdG9ycygwKQorICAgICAgICAsIG1fbXV0ZXgoYWRvcHRQdHIobmV3IE11dGV4KSkKICNl
bmRpZgogICAgIHsKICAgICAgICAgLy8gQ29weSB0aGUgaGFzaCB0YWJsZSB0aGUgZHVtYiB3YXks
IGJ5IGFkZGluZyBlYWNoIGVsZW1lbnQgdG8gdGhlIG5ldyB0YWJsZS4KQEAgLTEwOTksNyArMTEw
OCw3IEBAIG5hbWVzcGFjZSBXVEYgewogICAgIHRlbXBsYXRlPHR5cGVuYW1lIEtleSwgdHlwZW5h
bWUgVmFsdWUsIHR5cGVuYW1lIEV4dHJhY3RvciwgdHlwZW5hbWUgSGFzaEZ1bmN0aW9ucywgdHlw
ZW5hbWUgVHJhaXRzLCB0eXBlbmFtZSBLZXlUcmFpdHM+CiAgICAgdm9pZCBIYXNoVGFibGU8S2V5
LCBWYWx1ZSwgRXh0cmFjdG9yLCBIYXNoRnVuY3Rpb25zLCBUcmFpdHMsIEtleVRyYWl0cz46Omlu
dmFsaWRhdGVJdGVyYXRvcnMoKQogICAgIHsKLSAgICAgICAgTXV0ZXhMb2NrZXIgbG9jayhtX211
dGV4KTsKKyAgICAgICAgTXV0ZXhMb2NrZXIgbG9jaygqbV9tdXRleCk7CiAgICAgICAgIGNvbnN0
X2l0ZXJhdG9yKiBuZXh0OwogICAgICAgICBmb3IgKGNvbnN0X2l0ZXJhdG9yKiBwID0gbV9pdGVy
YXRvcnM7IHA7IHAgPSBuZXh0KSB7CiAgICAgICAgICAgICBuZXh0ID0gcC0+bV9uZXh0OwpAQCAt
MTEyMSw3ICsxMTMwLDcgQEAgbmFtZXNwYWNlIFdURiB7CiAgICAgICAgIGlmICghdGFibGUpIHsK
ICAgICAgICAgICAgIGl0LT5tX25leHQgPSAwOwogICAgICAgICB9IGVsc2UgewotICAgICAgICAg
ICAgTXV0ZXhMb2NrZXIgbG9jayh0YWJsZS0+bV9tdXRleCk7CisgICAgICAgICAgICBNdXRleExv
Y2tlciBsb2NrKCp0YWJsZS0+bV9tdXRleCk7CiAgICAgICAgICAgICBBU1NFUlQodGFibGUtPm1f
aXRlcmF0b3JzICE9IGl0KTsKICAgICAgICAgICAgIGl0LT5tX25leHQgPSB0YWJsZS0+bV9pdGVy
YXRvcnM7CiAgICAgICAgICAgICB0YWJsZS0+bV9pdGVyYXRvcnMgPSBpdDsKQEAgLTExNDMsNyAr
MTE1Miw3IEBAIG5hbWVzcGFjZSBXVEYgewogICAgICAgICAgICAgQVNTRVJUKCFpdC0+bV9uZXh0
KTsKICAgICAgICAgICAgIEFTU0VSVCghaXQtPm1fcHJldmlvdXMpOwogICAgICAgICB9IGVsc2Ug
ewotICAgICAgICAgICAgTXV0ZXhMb2NrZXIgbG9jayhpdC0+bV90YWJsZS0+bV9tdXRleCk7Cisg
ICAgICAgICAgICBNdXRleExvY2tlciBsb2NrKCppdC0+bV90YWJsZS0+bV9tdXRleCk7CiAgICAg
ICAgICAgICBpZiAoaXQtPm1fbmV4dCkgewogICAgICAgICAgICAgICAgIEFTU0VSVChpdC0+bV9u
ZXh0LT5tX3ByZXZpb3VzID09IGl0KTsKICAgICAgICAgICAgICAgICBpdC0+bV9uZXh0LT5tX3By
ZXZpb3VzID0gaXQtPm1fcHJldmlvdXM7CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL3d0Zi9UaHJl
YWRpbmdQdGhyZWFkcy5jcHAgYi9Tb3VyY2UvV1RGL3d0Zi9UaHJlYWRpbmdQdGhyZWFkcy5jcHAK
aW5kZXggYWJkMzUwZC4uZjU3ZjMyMiAxMDA2NDQKLS0tIGEvU291cmNlL1dURi93dGYvVGhyZWFk
aW5nUHRocmVhZHMuY3BwCisrKyBiL1NvdXJjZS9XVEYvd3RmL1RocmVhZGluZ1B0aHJlYWRzLmNw
cApAQCAtMjg4LDE0ICsyODgsMTYgQEAgTXV0ZXg6Ok11dGV4KCkKICAgICBwdGhyZWFkX211dGV4
YXR0cl9pbml0KCZhdHRyKTsKICAgICBwdGhyZWFkX211dGV4YXR0cl9zZXR0eXBlKCZhdHRyLCBQ
VEhSRUFEX01VVEVYX05PUk1BTCk7CiAKLSAgICBwdGhyZWFkX211dGV4X2luaXQoJm1fbXV0ZXgs
ICZhdHRyKTsKKyAgICBpbnQgcmVzdWx0ID0gcHRocmVhZF9tdXRleF9pbml0KCZtX211dGV4LCAm
YXR0cik7CisgICAgQVNTRVJUX1VOVVNFRChyZXN1bHQsICFyZXN1bHQpOwogCiAgICAgcHRocmVh
ZF9tdXRleGF0dHJfZGVzdHJveSgmYXR0cik7CiB9CiAKIE11dGV4Ojp+TXV0ZXgoKQogewotICAg
IHB0aHJlYWRfbXV0ZXhfZGVzdHJveSgmbV9tdXRleCk7CisgICAgaW50IHJlc3VsdCA9IHB0aHJl
YWRfbXV0ZXhfZGVzdHJveSgmbV9tdXRleCk7CisgICAgQVNTRVJUX1VOVVNFRChyZXN1bHQsICFy
ZXN1bHQpOwogfQogCiB2b2lkIE11dGV4Ojpsb2NrKCkK
</data>

          </attachment>
      

    </bug>

</bugzilla>