<?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>99178</bug_id>
          
          <creation_ts>2012-10-12 07:46:11 -0700</creation_ts>
          <short_desc>[JSC] DOM URL is flaky when workers are used</short_desc>
          <delta_ts>2012-11-01 10:59:50 -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>DOM</component>
          <version>420+</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>
          
          <blocked>99053</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Allan Sandfeld Jensen">allan.jensen</reporter>
          <assigned_to name="Allan Sandfeld Jensen">allan.jensen</assigned_to>
          <cc>abarth</cc>
    
    <cc>ap</cc>
    
    <cc>barraclough</cc>
    
    <cc>eric.carlson</cc>
    
    <cc>eric</cc>
    
    <cc>fpizlo</cc>
    
    <cc>ggaren</cc>
    
    <cc>haraken</cc>
    
    <cc>japhet</cc>
    
    <cc>jianli</cc>
    
    <cc>mhahnenberg</cc>
    
    <cc>oliver</cc>
    
    <cc>ossy</cc>
    
    <cc>roger_fong</cc>
    
    <cc>tkent</cc>
    
    <cc>webkit.review.bot</cc>
    
    <cc>zan</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>740909</commentid>
    <comment_count>0</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 07:46:11 -0700</bug_when>
    <thetext>When the DOM URL Constructor is used in both a main thread and a worker thread, the results becomes unstable. Specifically the methods will be likely to become undefined in one of the contexts (for JSC in V8 it seems to crash).

The reason seems to be that HashTable::createTable in Lookup.h registers the method names, only in the current context, once another context accesses the same table, it will be unable to lookup the identifiers used to access the methods.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740911</commentid>
    <comment_count>1</comment_count>
      <attachid>168420</attachid>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 07:52:43 -0700</bug_when>
    <thetext>Created attachment 168420
TestCase

A simple test-case. Window.URL.createObjectURL will be undefined in the main-thread because the table for JSDOMURL was created in the worker thread context.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740921</commentid>
    <comment_count>2</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 08:17:23 -0700</bug_when>
    <thetext>Besides the attached test-case, this bug affects the existing tests fast/files/workers/worker-apply-blob-url-to-xhr.html and fast/files/workers/worker-read-blob-async.html</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740930</commentid>
    <comment_count>3</comment_count>
      <attachid>168423</attachid>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 08:31:47 -0700</bug_when>
    <thetext>Created attachment 168423
Patch

A proof-of-concept patch. The patch solves the issue, but I am guessing this solution could cause preformance regressions. Putting it for review anyway to get feedback on this tricky issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740939</commentid>
    <comment_count>4</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 08:52:51 -0700</bug_when>
    <thetext>Clarifying the descriptions. What happens is that the method names such &quot;createObjectURL&quot; becomes different StringImpl pointers in different threads. This is probably a good idea since StringImpl is not thread-safe. Unfortunately the HashTable uses the StringImpl pointer as the key in it table. This means it will fail to find the correct methods when asked to do a lookup with a StringImpl* from another thread than the one the table was instantiated in.

The reason it causes flakiness is one, that the table is instantiated lazy, and two, that these tables can survive page-reload. Making it depend on both timing and what has been run before.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740948</commentid>
    <comment_count>5</comment_count>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2012-10-12 09:03:40 -0700</bug_when>
    <thetext>Your instinct is right that comparing Strings instead of StringImpl*s is a performance issue.

Typically, we solve threading problems with strings by making an isolatedCopy() before moving a string to another thread. Can you explain why that technique doesn&apos;t work in this case?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>740983</commentid>
    <comment_count>6</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 09:49:34 -0700</bug_when>
    <thetext>(In reply to comment #5)
&gt; Your instinct is right that comparing Strings instead of StringImpl*s is a performance issue.
&gt; 
&gt; Typically, we solve threading problems with strings by making an isolatedCopy() before moving a string to another thread. Can you explain why that technique doesn&apos;t work in this case?

There are no string moved from one thread to another here. This is a special case of a DOM object that is shared between different threads. As far as I can tell there are almost no other global DOM objects shared the same way, the only ones I could find with a quick scan were the element factories and the Notifications API.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>741027</commentid>
    <comment_count>7</comment_count>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2012-10-12 10:55:16 -0700</bug_when>
    <thetext>&gt; There are no string moved from one thread to another here. This is a special case of a DOM object that is shared between different threads.

OK. It&apos;s invalid in WebKit to share a DOM object between threads. In addition to this specific JavaScript issue, all AtomicString usage will be broken, string reference counting will be broken, and reference counting of the DOM url object will be broken.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>741037</commentid>
    <comment_count>8</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-12 11:06:24 -0700</bug_when>
    <thetext>(In reply to comment #7)
&gt; &gt; There are no string moved from one thread to another here. This is a special case of a DOM object that is shared between different threads.
&gt; 
&gt; OK. It&apos;s invalid in WebKit to share a DOM object between threads. In addition to this specific JavaScript issue, all AtomicString usage will be broken, string reference counting will be broken, and reference counting of the DOM url object will be broken.

Yeah, it thought it was kinda of crazy too, but since is the first time I am in contact with this code I do not know what thoughts went into the current design. The commit that changed it from being dynamically allocated in the workers, state that it was changed to being a static object due to the specification; but I don&apos;t think that necessarily should require us to share the method tables between all users of the object.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>741155</commentid>
    <comment_count>9</comment_count>
      <attachid>168423</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2012-10-12 13:35:06 -0700</bug_when>
    <thetext>Comment on attachment 168423
Patch

As you are new to this code, I&apos;ll also mention that JSNoStaticTables is what prevents sharing tables between objects and workers and ones on main thread.

Sharing a single object just isn&apos;t going to work for more reasons that just method tables, as Geoff explained.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>741864</commentid>
    <comment_count>10</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-15 02:05:03 -0700</bug_when>
    <thetext>(In reply to comment #9)
&gt; (From update of attachment 168423 [details])
&gt; As you are new to this code, I&apos;ll also mention that JSNoStaticTables is what prevents sharing tables between objects and workers and ones on main thread.
&gt; 

From inspecting the generated code it looks like JSNoStaticTables ensures that JSDOMURL::getOwnPropertySlot goes through separate tables for each GlobalData. The problem is then that these methods are accessed through JSDOMURLConstructor::getOwnPropertySlot which does not look up separate tables for each GlobalDAta.

Compare:

bool JSDOMURLConstructor::getOwnPropertySlot(JSCell* cell, ExecState* exec, PropertyName propertyName, PropertySlot&amp; slot)
{
    return getStaticPropertySlot&lt;JSDOMURLConstructor, JSDOMWrapper&gt;(exec, &amp;JSDOMURLConstructorTable, jsCast&lt;JSDOMURLConstructor*&gt;(cell), propertyName, slot);
}

bool JSDOMURL::getOwnPropertySlot(JSCell* cell, ExecState* exec, PropertyName propertyName, PropertySlot&amp; slot)
{
    JSDOMURL* thisObject = jsCast&lt;JSDOMURL*&gt;(cell);
    ASSERT_GC_OBJECT_INHERITS(thisObject, &amp;s_info);
    return getStaticValueSlot&lt;JSDOMURL, Base&gt;(exec, getJSDOMURLTable(exec), thisObject, propertyName, slot);
}

If I instrument the source-code, I never see calls to JSDOMURL::getOwnPropertySlot, but accessing URL.createObjectURL will instead access JSValue JSDOMURL::getConstructor and then  JSDOMURLConstructor::getOwnPropertySlot.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>741885</commentid>
    <comment_count>11</comment_count>
      <attachid>168658</attachid>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-15 02:50:34 -0700</bug_when>
    <thetext>Created attachment 168658
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>745088</commentid>
    <comment_count>12</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-18 01:53:25 -0700</bug_when>
    <thetext>The attached patch trivially extends the JSNoStaticTable mechanism to also create separate static tables for constructor objects, and it solves this bug, but I need someone more experienced in this code to tell if there was a reason this had not already been done to constructor objects, or if it was just an oversight.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>745268</commentid>
    <comment_count>13</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2012-10-18 08:16:32 -0700</bug_when>
    <thetext>Historically, this was an oversight - I know because I wrote it. But I&apos;m not qualified enough to review.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>745614</commentid>
    <comment_count>14</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2012-10-18 15:12:18 -0700</bug_when>
    <thetext>I&apos;m certain one of the JSC ninjas can set you straight here.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>753609</commentid>
    <comment_count>15</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-29 10:52:46 -0700</bug_when>
    <thetext>Ping, are none of JSC reviewers among the CC&apos;ed able to review this patch?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>753626</commentid>
    <comment_count>16</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2012-10-29 11:07:57 -0700</bug_when>
    <thetext>Add Papa JSC.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>754794</commentid>
    <comment_count>17</comment_count>
      <attachid>168658</attachid>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2012-10-30 16:49:36 -0700</bug_when>
    <thetext>Comment on attachment 168658
Patch

r=me</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>754860</commentid>
    <comment_count>18</comment_count>
      <attachid>168658</attachid>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-10-30 18:43:21 -0700</bug_when>
    <thetext>Comment on attachment 168658
Patch

Clearing flags on attachment: 168658

Committed r132973: &lt;http://trac.webkit.org/changeset/132973&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>754862</commentid>
    <comment_count>19</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-10-30 18:43:26 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>755010</commentid>
    <comment_count>20</comment_count>
    <who name="Csaba Osztrogonác">ossy</who>
    <bug_when>2012-10-30 23:53:46 -0700</bug_when>
    <thetext>(In reply to comment #18)
&gt; (From update of attachment 168658 [details])
&gt; Clearing flags on attachment: 168658
&gt; 
&gt; Committed r132973: &lt;http://trac.webkit.org/changeset/132973&gt;

It broke the bindings tests. Could you fix it?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>755123</commentid>
    <comment_count>21</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-31 03:55:05 -0700</bug_when>
    <thetext>Needs to have a fixup on the bindings tests, since they compare generated CPP output instead of functionality change.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>755126</commentid>
    <comment_count>22</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-10-31 04:00:25 -0700</bug_when>
    <thetext>Committed r133007: &lt;http://trac.webkit.org/changeset/133007&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>755767</commentid>
    <comment_count>23</comment_count>
    <who name="Roger Fong">roger_fong</who>
    <bug_when>2012-10-31 18:10:28 -0700</bug_when>
    <thetext>Test fails on Apple Windows port.
-PASS: window.URL.createObjectURL defined
-PASS: window.URL.revokeObjectURL defined
-PASS: URL.createObjectURL defined
-PASS: URL.revokeObjectURL defined
-PASS: window.URL.createObjectURL defined
-PASS: window.URL.revokeObjectURL defined
+CONSOLE MESSAGE: line 28: TypeError: &apos;undefined&apos; is not an object (evaluating &apos;window.URL.createObjectURL&apos;)
+FAIL: Timed out waiting for notifyDone to be called
 
Looks like window.URL is null? I can&apos;t test further because DRT seems to be broken on Windows right now :/</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>756018</commentid>
    <comment_count>24</comment_count>
    <who name="Zan Dobersek">zan</who>
    <bug_when>2012-11-01 02:40:42 -0700</bug_when>
    <thetext>*** Bug 100136 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>756087</commentid>
    <comment_count>25</comment_count>
    <who name="Allan Sandfeld Jensen">allan.jensen</who>
    <bug_when>2012-11-01 04:28:35 -0700</bug_when>
    <thetext>(In reply to comment #23)
&gt; Test fails on Apple Windows port.
&gt; -PASS: window.URL.createObjectURL defined
&gt; -PASS: window.URL.revokeObjectURL defined
&gt; -PASS: URL.createObjectURL defined
&gt; -PASS: URL.revokeObjectURL defined
&gt; -PASS: window.URL.createObjectURL defined
&gt; -PASS: window.URL.revokeObjectURL defined
&gt; +CONSOLE MESSAGE: line 28: TypeError: &apos;undefined&apos; is not an object (evaluating &apos;window.URL.createObjectURL&apos;)
&gt; +FAIL: Timed out waiting for notifyDone to be called
&gt; 
&gt; Looks like window.URL is null? I can&apos;t test further because DRT seems to be broken on Windows right now :/

Maybe you do not have BLOB enabled? In that case you need to skip this test.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>756456</commentid>
    <comment_count>26</comment_count>
    <who name="Roger Fong">roger_fong</who>
    <bug_when>2012-11-01 10:59:50 -0700</bug_when>
    <thetext>Ah yup, that would be it. Thanks, I&apos;ll add it on.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>168420</attachid>
            <date>2012-10-12 07:52:43 -0700</date>
            <delta_ts>2012-10-12 07:52:43 -0700</delta_ts>
            <desc>TestCase</desc>
            <filename>Study</filename>
            <type>application/octet-stream</type>
            <size>1828</size>
            <attacher name="Allan Sandfeld Jensen">allan.jensen</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy9yZXNvdXJjZXMvd29ya2VyLWRv
bXVybC5qcyBiL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy9yZXNvdXJjZXMvd29ya2VyLWRvbXVy
bC5qcwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi40MGYzMjZiCi0tLSAvZGV2
L251bGwKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3Jlc291cmNlcy93b3JrZXItZG9t
dXJsLmpzCkBAIC0wLDAgKzEsMTkgQEAKK2Z1bmN0aW9uIGxvZyhtZXNzYWdlKQoreworICAgIHBv
c3RNZXNzYWdlKG1lc3NhZ2UpOworfQorCitvbm1lc3NhZ2UgPSBmdW5jdGlvbihldmVudCkKK3sK
KyAgICBpZiAoc2VsZi5VUkwuY3JlYXRlT2JqZWN0VVJMID09IHVuZGVmaW5lZCkKKyAgICAgICAg
bG9nKCdGQUlMOiBVUkwuY3JlYXRlT2JqZWN0VVJMIHVuZGVmaW5lZCcpOworICAgIGVsc2UKKyAg
ICAgICAgbG9nKCdQQVNTOiBVUkwuY3JlYXRlT2JqZWN0VVJMIGRlZmluZWQnKTsKKworICAgIGlm
IChzZWxmLlVSTC5yZXZva2VPYmplY3RVUkwgPT0gdW5kZWZpbmVkKQorICAgICAgICBsb2coJ0ZB
SUw6IFVSTC5yZXZva2VPYmplY3RVUkwgdW5kZWZpbmVkJyk7CisgICAgZWxzZQorICAgICAgICBs
b2coJ1BBU1M6IFVSTC5yZXZva2VPYmplY3RVUkwgZGVmaW5lZCcpOworCisgICAgbG9nKCdET05F
Jyk7Cit9CmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9mYXN0L3dvcmtlcnMvd29ya2VyLWRvbXVy
bC5odG1sIGIvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3dvcmtlci1kb211cmwuaHRtbApuZXcg
ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5iZTZkN2UxCi0tLSAvZGV2L251bGwKKysr
IGIvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3dvcmtlci1kb211cmwuaHRtbApAQCAtMCwwICsx
LDM5IEBACis8IURPQ1RZUEUgaHRtbD4KKzxodG1sPgorPGJvZHk+Cis8cHJlIGlkPSdjb25zb2xl
Jz48L3ByZT4KKworPHNjcmlwdD4KK2Z1bmN0aW9uIGxvZyhtZXNzYWdlKQoreworICAgIGRvY3Vt
ZW50LmdldEVsZW1lbnRCeUlkKCdjb25zb2xlJykuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRl
VGV4dE5vZGUobWVzc2FnZSArICJcbiIpKTsKK30KKworZnVuY3Rpb24gcnVuVGVzdCgpIHsKKyAg
ICB2YXIgd29ya2VyID0gbmV3IFdvcmtlcigncmVzb3VyY2VzL3dvcmtlci1kb211cmwuanMnKTsK
KyAgICB3b3JrZXIub25tZXNzYWdlID0gZnVuY3Rpb24oZXZlbnQpIHsKKyAgICAgICAgbG9nKGV2
ZW50LmRhdGEpOworICAgICAgICBpZiAoZXZlbnQuZGF0YSA9PSAnRE9ORScpIHsKKyAgICAgICAg
ICAgIGlmICh3aW5kb3cudGVzdFJ1bm5lcikKKyAgICAgICAgICAgICAgICB0ZXN0UnVubmVyLm5v
dGlmeURvbmUoKTsKKyAgICAgICAgICAgIGlmICh3aW5kb3cuVVJMLmNyZWF0ZU9iamVjdFVSTCA9
PSB1bmRlZmluZWQpCisgICAgICAgICAgICAgICAgbG9nKCdGQUlMMicpOworICAgICAgICAgICAg
ZWxzZQorICAgICAgICAgICAgICAgIGxvZygnUEFTUzInKTsKKyAgICAgICAgfQorICAgIH0KKy8v
ICAgICBpZiAoVVJMLmNyZWF0ZU9iamVjdFVSTCA9PSB1bmRlZmluZWQpCisvLyAgICAgICAgIGxv
ZygnRkFJTDEnKTsKKy8vICAgICBlbHNlCisvLyAgICAgICAgIGxvZygnUEFTUzEnKTsKKyAgICB3
b3JrZXIucG9zdE1lc3NhZ2UoJycpOworfQorCitpZiAod2luZG93LnRlc3RSdW5uZXIpIHsKKyAg
ICB0ZXN0UnVubmVyLmR1bXBBc1RleHQoKTsKKyAgICB0ZXN0UnVubmVyLndhaXRVbnRpbERvbmUo
KTsKK30KK3dpbmRvdy5vbmxvYWQgPSBydW5UZXN0OworPC9zY3JpcHQ+Cis8L2JvZHk+Cis8L2h0
bWw+Cg==
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>168423</attachid>
            <date>2012-10-12 08:31:47 -0700</date>
            <delta_ts>2012-10-15 02:50:29 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-99178-20121012173025.patch</filename>
            <type>text/plain</type>
            <size>1516</size>
            <attacher name="Allan Sandfeld Jensen">allan.jensen</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTMxMDU3CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw
dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBj
ZTZlZjY2YzEyZWUzNDlkYjY2MTVhY2E5ZTQ3ZmY5Y2Q5NzdlY2VhLi5hOTliZjIyZmVlM2JlODQz
YzZjZDEwMTE1ZWZlNTQyZjNkZTFhZTk0IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv
cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs
MyArMSwxOCBAQAorMjAxMi0xMC0xMiAgQWxsYW4gU2FuZGZlbGQgSmVuc2VuICA8YWxsYW4uamVu
c2VuQGRpZ2lhLmNvbT4KKworICAgICAgICBET00gVVJMIGlzIGZsYWt5IHdoZW4gd29ya2VycyBh
cmUgdXNlZAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9
OTkxNzgKKworICAgICAgICBQcm9vZiBvZiBjb25jZXB0IHBhdGNoLiAKKyAgICAgICAgUmV2aWV3
ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgUmVwbGFjZXMgU3RyaW5nSW1wbCBjb21w
YXJpc29uIHdpdGggU3RyaW5nIGNvbXBhcmlzb24sIHNvIHRoYXQgbWV0aG9kIGxvb2t1cCB3b3Jr
cworICAgICAgICBhY3Jvc3MgdGhyZWFkcy4gVGhlIHBvdGVudGlhbCBwZXJmb3JtYW5jZSBpbXBh
Y3QgaG93ZXZlciBwcm9iYWJseSBtYWtlcyB0aGUgcGF0Y2gKKyAgICAgICAgdW5hY2NlcHRhYmxl
LCBhbmQgdGh1cyBvbmx5IGEgcHJvb2Ytb2YtY29uY2VwdC4KKworICAgICAgICAqIHJ1bnRpbWUv
TG9va3VwLmg6CisgICAgICAgIChKU0M6Okhhc2hUYWJsZTo6ZW50cnkpOgorCiAyMDEyLTEwLTEw
ICBab2x0YW4gSG9ydmF0aCAgPHpvbHRhbkB3ZWJraXQub3JnPgogCiAgICAgICAgIFBhZ2Vsb2Fk
IHRlc3RzIHNob3VsZCBtZWFzdXJlIG1lbW9yeSB1c2FnZQpkaWZmIC0tZ2l0IGEvU291cmNlL0ph
dmFTY3JpcHRDb3JlL3J1bnRpbWUvTG9va3VwLmggYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVu
dGltZS9Mb29rdXAuaAppbmRleCBjY2IwODEyOGQyMjFlZTFjOTIzNmQ1M2YzMzJkNjY5YmFmYTM2
ZjNiLi4xNzlhMWE0ZTg5NTIyZjA2ZjU4MjU3YjE3N2I2MWMzNzY4MTQ2ZjM1IDEwMDY0NAotLS0g
YS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9Mb29rdXAuaAorKysgYi9Tb3VyY2UvSmF2
YVNjcmlwdENvcmUvcnVudGltZS9Mb29rdXAuaApAQCAtMjIwLDcgKzIyMCw3IEBAIG5hbWVzcGFj
ZSBKU0MgewogICAgICAgICAgICAgICAgIHJldHVybiAwOwogCiAgICAgICAgICAgICBkbyB7Ci0g
ICAgICAgICAgICAgICAgaWYgKGVudHJ5LT5rZXkoKSA9PSBpbXBsKQorICAgICAgICAgICAgICAg
IGlmIChTdHJpbmcoZW50cnktPmtleSgpKSA9PSBTdHJpbmcoaW1wbCkpCiAgICAgICAgICAgICAg
ICAgICAgIHJldHVybiBlbnRyeTsKICAgICAgICAgICAgICAgICBlbnRyeSA9IGVudHJ5LT5uZXh0
KCk7CiAgICAgICAgICAgICB9IHdoaWxlIChlbnRyeSk7Cg==
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>168658</attachid>
            <date>2012-10-15 02:50:34 -0700</date>
            <delta_ts>2012-10-30 18:43:21 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-99178-20121015114907.patch</filename>
            <type>text/plain</type>
            <size>8229</size>
            <attacher name="Allan Sandfeld Jensen">allan.jensen</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTMxMjkxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D
aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggMDBlZmVhOWY2YWJjNzM5
Njg0NWUyOGZjNzY3Yzg3ZTAyMTYzOTVkZC4uYmMzYzlmZWFkYmNlMDhlMjI5ZWIyYTlmMDBjYTcw
NzJiOTI2NzE4ZiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv
dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE4IEBACisyMDEyLTEwLTE1ICBBbGxh
biBTYW5kZmVsZCBKZW5zZW4gIDxhbGxhbi5qZW5zZW5AZGlnaWEuY29tPgorCisgICAgICAgIERP
TSBVUkwgaXMgZmxha3kgd2hlbiB3b3JrZXJzIGFyZSB1c2VkCisgICAgICAgIGh0dHBzOi8vYnVn
cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05OTE3OAorCisgICAgICAgIFJldmlld2VkIGJ5
IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEV4dGVuZCBKU05vU3RhdGljVGFibGVzIHRvIGFs
c28gYXZvaWQgZGlyZWN0IGFjY2VzcyBvZiBzdGF0aWMgdGFibGVzIGluIGNvbnN0cnVjdG9yIG9i
amVjdHMuCisKKyAgICAgICAgVGVzdDogZmFzdC93b3JrZXJzL3dvcmtlci1kb211cmwuaHRtbAor
CisgICAgICAgICogYmluZGluZ3Mvc2NyaXB0cy9Db2RlR2VuZXJhdG9ySlMucG06CisgICAgICAg
IChjb25zdHJ1Y3Rvckhhc2hUYWJsZUFjY2Vzc29yKToKKyAgICAgICAgKEdlbmVyYXRlQ29uc3Ry
dWN0b3JEZWZpbml0aW9uKToKKwogMjAxMi0xMC0xMSAgQWxsYW4gU2FuZGZlbGQgSmVuc2VuICA8
YWxsYW4uamVuc2VuQGRpZ2lhLmNvbT4KIAogICAgICAgICBbUXRdIEhhbmRsZSBHRVQgb2YgYmxv
YiBVUkxzLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvYmluZGluZ3Mvc2NyaXB0cy9Db2Rl
R2VuZXJhdG9ySlMucG0gYi9Tb3VyY2UvV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL0NvZGVHZW5l
cmF0b3JKUy5wbQppbmRleCA0NzU0ZDNmNWEzM2EyNjEwYzBhYjFkZDU1MDYzNTczNDUyMGViZWEy
Li4wYzEyMTAyYzg0Nzk3YjViMWE3YWZkNGRlNzFlMDE2M2E5MDVlYjA2IDEwMDY0NAotLS0gYS9T
b3VyY2UvV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL0NvZGVHZW5lcmF0b3JKUy5wbQorKysgYi9T
b3VyY2UvV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL0NvZGVHZW5lcmF0b3JKUy5wbQpAQCAtMzcx
LDYgKzM3MSwxNyBAQCBzdWIgcHJvdG90eXBlSGFzaFRhYmxlQWNjZXNzb3IKICAgICB9CiB9CiAK
K3N1YiBjb25zdHJ1Y3Rvckhhc2hUYWJsZUFjY2Vzc29yCit7CisgICAgbXkgJG5vU3RhdGljVGFi
bGVzID0gc2hpZnQ7CisgICAgbXkgJGNvbnN0cnVjdG9yQ2xhc3NOYW1lID0gc2hpZnQ7CisgICAg
aWYgKCRub1N0YXRpY1RhYmxlcykgeworICAgICAgICByZXR1cm4gImdldCR7Y29uc3RydWN0b3JD
bGFzc05hbWV9VGFibGUoZXhlYykiOworICAgIH0gZWxzZSB7CisgICAgICAgIHJldHVybiAiJiR7
Y29uc3RydWN0b3JDbGFzc05hbWV9VGFibGUiOworICAgIH0KK30KKwogc3ViIEdldEdlbmVyYXRl
SXNSZWFjaGFibGUKIHsKICAgICBteSAkZGF0YU5vZGUgPSBzaGlmdDsKQEAgLTM3MTksNyArMzcz
MCwxNiBAQCBzdWIgR2VuZXJhdGVDb25zdHJ1Y3RvckRlZmluaXRpb24KICAgICAgICAgcHVzaChA
JG91dHB1dEFycmF5LCAie1xuIik7CiAgICAgICAgIHB1c2goQCRvdXRwdXRBcnJheSwgIn1cblxu
Iik7CiAgICAgfSBlbHNlIHsKLSAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAiY29uc3QgQ2xh
c3NJbmZvICR7Y29uc3RydWN0b3JDbGFzc05hbWV9OjpzX2luZm8gPSB7IFwiJHt2aXNpYmxlSW50
ZXJmYWNlTmFtZX1Db25zdHJ1Y3RvclwiLCAmQmFzZTo6c19pbmZvLCAmJHtjb25zdHJ1Y3RvckNs
YXNzTmFtZX1UYWJsZSwgMCwgQ1JFQVRFX01FVEhPRF9UQUJMRSgkY29uc3RydWN0b3JDbGFzc05h
bWUpIH07XG5cbiIpOworICAgICAgICBpZiAoJGRhdGFOb2RlLT5leHRlbmRlZEF0dHJpYnV0ZXMt
PnsiSlNOb1N0YXRpY1RhYmxlcyJ9KSB7CisgICAgICAgICAgICBwdXNoKEAkb3V0cHV0QXJyYXks
ICJzdGF0aWMgY29uc3QgSGFzaFRhYmxlKiBnZXQke2NvbnN0cnVjdG9yQ2xhc3NOYW1lfVRhYmxl
KEV4ZWNTdGF0ZSogZXhlYylcbiIpOworICAgICAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAi
e1xuIik7CisgICAgICAgICAgICBwdXNoKEAkb3V0cHV0QXJyYXksICIgICAgcmV0dXJuIGdldEhh
c2hUYWJsZUZvckdsb2JhbERhdGEoZXhlYy0+Z2xvYmFsRGF0YSgpLCAmJHtjb25zdHJ1Y3RvckNs
YXNzTmFtZX1UYWJsZSk7XG4iKTsKKyAgICAgICAgICAgIHB1c2goQCRvdXRwdXRBcnJheSwgIn1c
blxuIik7CisgICAgICAgICAgICBwdXNoKEAkb3V0cHV0QXJyYXksICJjb25zdCBDbGFzc0luZm8g
JHtjb25zdHJ1Y3RvckNsYXNzTmFtZX06OnNfaW5mbyA9IHsgXCIke3Zpc2libGVJbnRlcmZhY2VO
YW1lfUNvbnN0cnVjdG9yXCIsICZCYXNlOjpzX2luZm8sIDAsIGdldCR7Y29uc3RydWN0b3JDbGFz
c05hbWV9VGFibGUsIENSRUFURV9NRVRIT0RfVEFCTEUoJGNvbnN0cnVjdG9yQ2xhc3NOYW1lKSB9
O1xuXG4iKTsKKyAgICAgICAgfSBlbHNlIHsKKyAgICAgICAgICAgIHB1c2goQCRvdXRwdXRBcnJh
eSwgImNvbnN0IENsYXNzSW5mbyAke2NvbnN0cnVjdG9yQ2xhc3NOYW1lfTo6c19pbmZvID0geyBc
IiR7dmlzaWJsZUludGVyZmFjZU5hbWV9Q29uc3RydWN0b3JcIiwgJkJhc2U6OnNfaW5mbywgJiR7
Y29uc3RydWN0b3JDbGFzc05hbWV9VGFibGUsIDAsIENSRUFURV9NRVRIT0RfVEFCTEUoJGNvbnN0
cnVjdG9yQ2xhc3NOYW1lKSB9O1xuXG4iKTsKKyAgICAgICAgfQorCiAgICAgICAgIHB1c2goQCRv
dXRwdXRBcnJheSwgIiR7Y29uc3RydWN0b3JDbGFzc05hbWV9Ojoke2NvbnN0cnVjdG9yQ2xhc3NO
YW1lfShTdHJ1Y3R1cmUqIHN0cnVjdHVyZSwgSlNET01HbG9iYWxPYmplY3QqIGdsb2JhbE9iamVj
dClcbiIpOwogICAgICAgICBwdXNoKEAkb3V0cHV0QXJyYXksICIgICAgOiBET01Db25zdHJ1Y3Rv
ck9iamVjdChzdHJ1Y3R1cmUsIGdsb2JhbE9iamVjdClcbiIpOwogICAgICAgICBwdXNoKEAkb3V0
cHV0QXJyYXksICJ7XG4iKTsKQEAgLTM3NTcsMTIgKzM3NzcsMTIgQEAgc3ViIEdlbmVyYXRlQ29u
c3RydWN0b3JEZWZpbml0aW9uCiAKICAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAiYm9vbCAk
e2NvbnN0cnVjdG9yQ2xhc3NOYW1lfTo6Z2V0T3duUHJvcGVydHlTbG90KEpTQ2VsbCogY2VsbCwg
RXhlY1N0YXRlKiBleGVjLCBQcm9wZXJ0eU5hbWUgcHJvcGVydHlOYW1lLCBQcm9wZXJ0eVNsb3Qm
IHNsb3QpXG4iKTsKICAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAie1xuIik7Ci0gICAgICAg
IHB1c2goQCRvdXRwdXRBcnJheSwgIiAgICByZXR1cm4gZ2V0U3RhdGljJHtraW5kfVNsb3Q8JHtj
b25zdHJ1Y3RvckNsYXNzTmFtZX0sIEpTRE9NV3JhcHBlcj4oZXhlYywgJiR7Y29uc3RydWN0b3JD
bGFzc05hbWV9VGFibGUsIGpzQ2FzdDwke2NvbnN0cnVjdG9yQ2xhc3NOYW1lfSo+KGNlbGwpLCBw
cm9wZXJ0eU5hbWUsIHNsb3QpO1xuIik7CisgICAgICAgIHB1c2goQCRvdXRwdXRBcnJheSwgIiAg
ICByZXR1cm4gZ2V0U3RhdGljJHtraW5kfVNsb3Q8JHtjb25zdHJ1Y3RvckNsYXNzTmFtZX0sIEpT
RE9NV3JhcHBlcj4oZXhlYywgIiAuIGNvbnN0cnVjdG9ySGFzaFRhYmxlQWNjZXNzb3IoJGRhdGFO
b2RlLT5leHRlbmRlZEF0dHJpYnV0ZXMtPnsiSlNOb1N0YXRpY1RhYmxlcyJ9LCAkY29uc3RydWN0
b3JDbGFzc05hbWUpIC4gIiwganNDYXN0PCR7Y29uc3RydWN0b3JDbGFzc05hbWV9Kj4oY2VsbCks
IHByb3BlcnR5TmFtZSwgc2xvdCk7XG4iKTsKICAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAi
fVxuXG4iKTsKIAogICAgICAgICBwdXNoKEAkb3V0cHV0QXJyYXksICJib29sICR7Y29uc3RydWN0
b3JDbGFzc05hbWV9OjpnZXRPd25Qcm9wZXJ0eURlc2NyaXB0b3IoSlNPYmplY3QqIG9iamVjdCwg
RXhlY1N0YXRlKiBleGVjLCBQcm9wZXJ0eU5hbWUgcHJvcGVydHlOYW1lLCBQcm9wZXJ0eURlc2Ny
aXB0b3ImIGRlc2NyaXB0b3IpXG4iKTsKICAgICAgICAgcHVzaChAJG91dHB1dEFycmF5LCAie1xu
Iik7Ci0gICAgICAgIHB1c2goQCRvdXRwdXRBcnJheSwgIiAgICByZXR1cm4gZ2V0U3RhdGljJHtr
aW5kfURlc2NyaXB0b3I8JHtjb25zdHJ1Y3RvckNsYXNzTmFtZX0sIEpTRE9NV3JhcHBlcj4oZXhl
YywgJiR7Y29uc3RydWN0b3JDbGFzc05hbWV9VGFibGUsIGpzQ2FzdDwke2NvbnN0cnVjdG9yQ2xh
c3NOYW1lfSo+KG9iamVjdCksIHByb3BlcnR5TmFtZSwgZGVzY3JpcHRvcik7XG4iKTsKKyAgICAg
ICAgcHVzaChAJG91dHB1dEFycmF5LCAiICAgIHJldHVybiBnZXRTdGF0aWMke2tpbmR9RGVzY3Jp
cHRvcjwke2NvbnN0cnVjdG9yQ2xhc3NOYW1lfSwgSlNET01XcmFwcGVyPihleGVjLCAiIC4gY29u
c3RydWN0b3JIYXNoVGFibGVBY2Nlc3NvcigkZGF0YU5vZGUtPmV4dGVuZGVkQXR0cmlidXRlcy0+
eyJKU05vU3RhdGljVGFibGVzIn0sICRjb25zdHJ1Y3RvckNsYXNzTmFtZSkgLiAiLCBqc0Nhc3Q8
JHtjb25zdHJ1Y3RvckNsYXNzTmFtZX0qPihvYmplY3QpLCBwcm9wZXJ0eU5hbWUsIGRlc2NyaXB0
b3IpO1xuIik7CiAgICAgICAgIHB1c2goQCRvdXRwdXRBcnJheSwgIn1cblxuIik7CiAgICAgfQog
CmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VM
b2cKaW5kZXggMWIyOGM2OGE4NTk2ZWZhZGM5NmRiOWIxZjdmOTY0NzgwNGQyMTRkZC4uN2I0NjM1
MzhlMDA5NTA0YzEzYTNhMzdmOGQ1M2E5ZTFiNmRhMWI2OSAxMDA2NDQKLS0tIGEvTGF5b3V0VGVz
dHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3RzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE4IEBA
CisyMDEyLTEwLTE1ICBBbGxhbiBTYW5kZmVsZCBKZW5zZW4gIDxhbGxhbi5qZW5zZW5AZGlnaWEu
Y29tPgorCisgICAgICAgIERPTSBVUkwgaXMgZmxha3kgd2hlbiB3b3JrZXJzIGFyZSB1c2VkCisg
ICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05OTE3OAorCisg
ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFRlc3QgdGhhdCB0
aGUgbWV0aG9kcyBvZiB0aGUgVVJMIGNvbnN0cnVjdG9yIGFyZSBhY2Nlc2libGUgZnJvbSBib3Ro
IG1haW4gYW5kIHdvcmtlciB0aHJlYWRzLgorCisgICAgICAgICogZmFzdC93b3JrZXJzL3Jlc291
cmNlcy93b3JrZXItZG9tdXJsLmpzOiBBZGRlZC4KKyAgICAgICAgKGxvZyk6CisgICAgICAgIChv
bm1lc3NhZ2UpOgorICAgICAgICAqIGZhc3Qvd29ya2Vycy93b3JrZXItZG9tdXJsLWV4cGVjdGVk
LnR4dDogQWRkZWQuCisgICAgICAgICogZmFzdC93b3JrZXJzL3dvcmtlci1kb211cmwuaHRtbDog
QWRkZWQuCisKIDIwMTItMTAtMTEgIEFsbGFuIFNhbmRmZWxkIEplbnNlbiAgPGFsbGFuLmplbnNl
bkBkaWdpYS5jb20+CiAKICAgICAgICAgW1F0XSBIYW5kbGUgR0VUIG9mIGJsb2IgVVJMcy4KZGlm
ZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy9yZXNvdXJjZXMvd29ya2VyLWRvbXVy
bC5qcyBiL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy9yZXNvdXJjZXMvd29ya2VyLWRvbXVybC5q
cwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwLi45ZDRkMjA3Yjk5NDJjYTg4Yzc3MGZkZTcxNjA5YmJiMTZjMjA2NDc1Ci0t
LSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3Jlc291cmNlcy93b3Jr
ZXItZG9tdXJsLmpzCkBAIC0wLDAgKzEsMTkgQEAKK2Z1bmN0aW9uIGxvZyhtZXNzYWdlKQorewor
ICAgIHBvc3RNZXNzYWdlKG1lc3NhZ2UpOworfQorCitvbm1lc3NhZ2UgPSBmdW5jdGlvbihldmVu
dCkKK3sKKyAgICBpZiAoVVJMLmNyZWF0ZU9iamVjdFVSTCA9PSB1bmRlZmluZWQpCisgICAgICAg
IGxvZygnRkFJTDogVVJMLmNyZWF0ZU9iamVjdFVSTCB1bmRlZmluZWQnKTsKKyAgICBlbHNlCisg
ICAgICAgIGxvZygnUEFTUzogVVJMLmNyZWF0ZU9iamVjdFVSTCBkZWZpbmVkJyk7CisKKyAgICBp
ZiAoVVJMLnJldm9rZU9iamVjdFVSTCA9PSB1bmRlZmluZWQpCisgICAgICAgIGxvZygnRkFJTDog
VVJMLnJldm9rZU9iamVjdFVSTCB1bmRlZmluZWQnKTsKKyAgICBlbHNlCisgICAgICAgIGxvZygn
UEFTUzogVVJMLnJldm9rZU9iamVjdFVSTCBkZWZpbmVkJyk7CisKKyAgICBsb2coJ0RPTkUnKTsK
K30KZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy93b3JrZXItZG9tdXJsLWV4
cGVjdGVkLnR4dCBiL0xheW91dFRlc3RzL2Zhc3Qvd29ya2Vycy93b3JrZXItZG9tdXJsLWV4cGVj
dGVkLnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwLi5iMmI2ZmRmY2Q0NmYxOGU5NTg0N2Q2MGUwOGFiOWNiZDEwMjZh
MWE1Ci0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3dvcmtlci1k
b211cmwtZXhwZWN0ZWQudHh0CkBAIC0wLDAgKzEsNyBAQAorUEFTUzogd2luZG93LlVSTC5jcmVh
dGVPYmplY3RVUkwgZGVmaW5lZAorUEFTUzogd2luZG93LlVSTC5yZXZva2VPYmplY3RVUkwgZGVm
aW5lZAorUEFTUzogVVJMLmNyZWF0ZU9iamVjdFVSTCBkZWZpbmVkCitQQVNTOiBVUkwucmV2b2tl
T2JqZWN0VVJMIGRlZmluZWQKK1BBU1M6IHdpbmRvdy5VUkwuY3JlYXRlT2JqZWN0VVJMIGRlZmlu
ZWQKK1BBU1M6IHdpbmRvdy5VUkwucmV2b2tlT2JqZWN0VVJMIGRlZmluZWQKKwpkaWZmIC0tZ2l0
IGEvTGF5b3V0VGVzdHMvZmFzdC93b3JrZXJzL3dvcmtlci1kb211cmwuaHRtbCBiL0xheW91dFRl
c3RzL2Zhc3Qvd29ya2Vycy93b3JrZXItZG9tdXJsLmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQK
aW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMC4uN2ExZDMzNTUw
NzFhMzI1ZmVkOGZjZTQ5M2YxNmU0MzAwOGEyZGJlMwotLS0gL2Rldi9udWxsCisrKyBiL0xheW91
dFRlc3RzL2Zhc3Qvd29ya2Vycy93b3JrZXItZG9tdXJsLmh0bWwKQEAgLTAsMCArMSw0NiBAQAor
PCFET0NUWVBFIGh0bWw+Cis8aHRtbD4KKzxib2R5PgorPHByZSBpZD0nY29uc29sZSc+PC9wcmU+
CisKKzxzY3JpcHQ+CitmdW5jdGlvbiBsb2cobWVzc2FnZSkKK3sKKyAgICBkb2N1bWVudC5nZXRF
bGVtZW50QnlJZCgnY29uc29sZScpLmFwcGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2Rl
KG1lc3NhZ2UgKyAiXG4iKSk7Cit9CisKK2Z1bmN0aW9uIHJ1blRlc3QoKSB7CisgICAgdmFyIHdv
cmtlciA9IG5ldyBXb3JrZXIoJ3Jlc291cmNlcy93b3JrZXItZG9tdXJsLmpzJyk7CisgICAgd29y
a2VyLm9ubWVzc2FnZSA9IGZ1bmN0aW9uKGV2ZW50KSB7CisgICAgICAgIGlmIChldmVudC5kYXRh
ID09ICdET05FJykgeworICAgICAgICAgICAgdGVzdERPTVVSTCgpOworICAgICAgICAgICAgaWYg
KHdpbmRvdy50ZXN0UnVubmVyKQorICAgICAgICAgICAgICAgIHRlc3RSdW5uZXIubm90aWZ5RG9u
ZSgpOworICAgICAgICB9IGVsc2UKKyAgICAgICAgICAgIGxvZyhldmVudC5kYXRhKTsKKyAgICB9
CisgICAgdGVzdERPTVVSTCgpOworICAgIHdvcmtlci5wb3N0TWVzc2FnZSgnJyk7Cit9CisKK2Z1
bmN0aW9uIHRlc3RET01VUkwoKSAKK3sKKyAgICBpZiAod2luZG93LlVSTC5jcmVhdGVPYmplY3RV
UkwgPT0gdW5kZWZpbmVkKQorICAgICAgICBsb2coJ0ZBSUw6IHdpbmRvdy5VUkwuY3JlYXRlT2Jq
ZWN0VVJMIHVuZGVmaW5lZCcpOworICAgIGVsc2UKKyAgICAgICAgbG9nKCdQQVNTOiB3aW5kb3cu
VVJMLmNyZWF0ZU9iamVjdFVSTCBkZWZpbmVkJyk7CisKKyAgICBpZiAod2luZG93LlVSTC5yZXZv
a2VPYmplY3RVUkwgPT0gdW5kZWZpbmVkKQorICAgICAgICBsb2coJ0ZBSUw6IHdpbmRvdy5VUkwu
cmV2b2tlT2JqZWN0VVJMIHVuZGVmaW5lZCcpOworICAgIGVsc2UKKyAgICAgICAgbG9nKCdQQVNT
OiB3aW5kb3cuVVJMLnJldm9rZU9iamVjdFVSTCBkZWZpbmVkJyk7Cit9CisKK2lmICh3aW5kb3cu
dGVzdFJ1bm5lcikgeworICAgIHRlc3RSdW5uZXIuZHVtcEFzVGV4dCgpOworICAgIHRlc3RSdW5u
ZXIud2FpdFVudGlsRG9uZSgpOworfQord2luZG93Lm9ubG9hZCA9IHJ1blRlc3Q7Cis8L3Njcmlw
dD4KKzwvYm9keT4KKzwvaHRtbD4K
</data>

          </attachment>
      

    </bug>

</bugzilla>