<?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>57640</bug_id>
          
          <creation_ts>2011-04-01 09:57:15 -0700</creation_ts>
          <short_desc>[GTK] overlapping drag&amp;drop tests fail on NRWT</short_desc>
          <delta_ts>2011-06-29 12:47:52 -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>Tools / Tests</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Linux</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>34984</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Tony Chang">tony</reporter>
          <assigned_to name="Xan Lopez">xan.lopez</assigned_to>
          <cc>dpranke</cc>
    
    <cc>mrobinson</cc>
    
    <cc>webkit.review.bot</cc>
    
    <cc>xan.lopez</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>377872</commentid>
    <comment_count>0</comment_count>
    <who name="Tony Chang">tony</who>
    <bug_when>2011-04-01 09:57:15 -0700</bug_when>
    <thetext>The GTK+ DRT makes real d&amp;d calls which can cause problems if two processes try to run a d&amp;d test at the same time.  A simple workaround is to give each NRWT process a separate Xvfb server to use.  This could probably happen in 2 different ways:

1) Each NRWT thread is taught to start/stop xvfb on it&apos;s own.
2) The buildbot slave wrapper scripts (Tools/BuildSlaveSupport/gtk/xvfb/run and gtk/buildbot/run) can launch N Xvfb processes and NRWT just needs to set the right DISPLAY for each process.

(1) sounds a bit easier than (2), but either is probably OK.

This might also give speed improvements.  Chromium Linux&apos;s DRT used to use to paint to the X server and Xvfb was always pegged at 100% cpu when running with 16 processes.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>381079</commentid>
    <comment_count>1</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2011-04-06 19:48:29 -0700</bug_when>
    <thetext>How many d&amp;d tests are there? Another way to do this is to put all of the d&amp;d tests into a single shard.

I&apos;m loathe to spin up multiple xvfb&apos;s, but maybe it makes sense to do so. We can certainly do some profiling to find out.

It would be kinda nice to have NRWT automatically start its own xvfb&apos;s rather than relying on the user to do so.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>381459</commentid>
    <comment_count>2</comment_count>
    <who name="Tony Chang">tony</who>
    <bug_when>2011-04-07 10:26:52 -0700</bug_when>
    <thetext>(In reply to comment #1)
&gt; How many d&amp;d tests are there? Another way to do this is to put all of the d&amp;d tests into a single shard.

There probably aren&apos;t that many, but they&apos;re not all in the same place (off the top of my head, some are in editing, some are in http, and some are in fast).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>416471</commentid>
    <comment_count>3</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-07 06:44:24 -0700</bug_when>
    <thetext>(In reply to comment #0)
&gt; The GTK+ DRT makes real d&amp;d calls which can cause problems if two processes try to run a d&amp;d test at the same time.  A simple workaround is to give each NRWT process a separate Xvfb server to use.  This could probably happen in 2 different ways:
&gt; 
&gt; 1) Each NRWT thread is taught to start/stop xvfb on it&apos;s own.
&gt; 2) The buildbot slave wrapper scripts (Tools/BuildSlaveSupport/gtk/xvfb/run and gtk/buildbot/run) can launch N Xvfb processes and NRWT just needs to set the right DISPLAY for each process.
&gt; 
&gt; (1) sounds a bit easier than (2), but either is probably OK.
&gt; 

We are interested in moving GTK+ over NWRT ASAP, so I&apos;m willing to spend some time on this. I&apos;ve been looking around the code and I was wondering what is the best way to implement this exactly. My first intuition would be to have a GTK+ Driver (like Chromium&apos;s) that knows how to deal with Xvfb, but I wonder if I&apos;d be reimplementing too much stuff here. Suggestions?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>416536</commentid>
    <comment_count>4</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2011-06-07 08:56:57 -0700</bug_when>
    <thetext>It should only be a couple of lines of code to launch an Xvfb prior to the DRT, and AFAIK that wouldn&apos;t be duplicating anything we have elsewhere, so I say go ahead. Seems like a reasonable fix.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417289</commentid>
    <comment_count>5</comment_count>
      <attachid>96434</attachid>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-08 09:33:04 -0700</bug_when>
    <thetext>Created attachment 96434
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417290</commentid>
    <comment_count>6</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-08 09:34:33 -0700</bug_when>
    <thetext>(In reply to comment #5)
&gt; Created an attachment (id=96434) [details]
&gt; Patch

A couple of comments:

- I had to copy the start method from the WebKit driver because I need to add things to the environment and the port method to set it up runs to soon (I don&apos;t know the worker number). I guess it can be fixed with some refactoring.

- The Xvfb processes are not killed if the test run is stopped with Ctrl-C, not sure how to do this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417292</commentid>
    <comment_count>7</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2011-06-08 09:34:41 -0700</bug_when>
    <thetext>Attachment 96434 did not pass style-queue:

Failed to run &quot;[&apos;Tools/Scripts/check-webkit-style&apos;, &apos;--diff-files&apos;, u&apos;Tools/ChangeLog&apos;, u&apos;Tools/Scripts/webkitpy...&quot; exit_code: 1

Tools/Scripts/webkitpy/layout_tests/port/gtk.py:41:  expected 2 blank lines, found 1  [pep8/E302] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417324</commentid>
    <comment_count>8</comment_count>
      <attachid>96434</attachid>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2011-06-08 10:20:07 -0700</bug_when>
    <thetext>Comment on attachment 96434
Patch

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

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:52
&gt; +        environment[&apos;DYLD_FRAMEWORK_PATH&apos;] = self._port._build_path()

Is this actually need for GTK+? This environment variable controls Framework loading on OS X.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417334</commentid>
    <comment_count>9</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-08 10:30:13 -0700</bug_when>
    <thetext>(In reply to comment #8)
&gt; (From update of attachment 96434 [details])
&gt; View in context: https://bugs.webkit.org/attachment.cgi?id=96434&amp;action=review
&gt; 
&gt; &gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:52
&gt; &gt; +        environment[&apos;DYLD_FRAMEWORK_PATH&apos;] = self._port._build_path()
&gt; 
&gt; Is this actually need for GTK+? This environment variable controls Framework loading on OS X.

I don&apos;t think we use any of the variables I copied, this one we don&apos;t for sure. I guess I just left it there in case we want to make this &quot;more portable&quot; and to keep the exact behavior we have now, but probably we should just make it GTK+-only for now.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>417475</commentid>
    <comment_count>10</comment_count>
      <attachid>96434</attachid>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2011-06-08 13:43:22 -0700</bug_when>
    <thetext>Comment on attachment 96434
Patch

(In reply to comment #6)
&gt; (In reply to comment #5)
&gt; &gt; Created an attachment (id=96434) [details] [details]
&gt; &gt; Patch
&gt; 
&gt; A couple of comments:
&gt; 
&gt; - I had to copy the start method from the WebKit driver because I need to add things to the environment and the port method to set it up runs to soon (I don&apos;t know the worker number). I guess it can be fixed with some refactoring.
&gt;

Overriding the start method is exactly what I&apos;d expect you to do. I don&apos;t think I&apos;d want to change or refactor anything, but maybe I&apos;m not understanding your concern?
 
&gt; - The Xvfb processes are not killed if the test run is stopped with Ctrl-C, not sure how to do this.

This is a problem. Is driver.stop() not getting called after the Ctrl-C is received? It should be. You can try adding a _log.debug() message and then running with --verbose to see what&apos;s going on one way or another; feel free to post the log or email it to me for help debugging it.


&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:37
&gt; +from webkitpy.layout_tests.port.webkit import WebKitPort, WebKitDriver

Nit: I usually prefer to just import the module, and prefix the symbols with the module name (so, webkit.WebKitPort below instead of just WebKitPort); I think Eric wrote this code originally before we converged on that style. You can change this or not as you like for now.

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:49
&gt; +        run_xvfb = [&quot;Xvfb&quot;, &quot;:%d&quot; % (self._worker_number + 1)]

Nit: I&apos;d probably do something like &apos;display_id = self._worker_number + 1&apos; here to make it clear and avoid having to do the computation twice.

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:50
&gt; +        self._process = subprocess.Popen(run_xvfb)

Can you rename this to self._xvfb_process or something like that? _process is a little too generic.

&gt;&gt;&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:52
&gt;&gt;&gt; +        environment[&apos;DYLD_FRAMEWORK_PATH&apos;] = self._port._build_path()
&gt;&gt; 
&gt;&gt; Is this actually need for GTK+? This environment variable controls Framework loading on OS X.
&gt; 
&gt; I don&apos;t think we use any of the variables I copied, this one we don&apos;t for sure. I guess I just left it there in case we want to make this &quot;more portable&quot; and to keep the exact behavior we have now, but probably we should just make it GTK+-only for now.

Definitely remove the DYLD_* and DUMPRENDERTREE_TEMP variables if you don&apos;t need them.

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:72
&gt; +        self._worker_number = worker_number

Do you need self._worker_number? I don&apos;t see it being used anywhere.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>418001</commentid>
    <comment_count>11</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-09 07:22:32 -0700</bug_when>
    <thetext>(In reply to comment #10)
&gt; Overriding the start method is exactly what I&apos;d expect you to do. I don&apos;t think I&apos;d want to change or refactor anything, but maybe I&apos;m not understanding your concern?

I meant that it seems to me I could just override the Port method to setup the initial environment and chain to the parent class&apos; start, but that runs too early for my needs (because I need to know the worker number), so in the end I just did my own start from scratch. No big deal, it&apos;s a tiny thing.

&gt; 
&gt; &gt; - The Xvfb processes are not killed if the test run is stopped with Ctrl-C, not sure how to do this.
&gt; 
&gt; This is a problem. Is driver.stop() not getting called after the Ctrl-C is received? It should be. You can try adding a _log.debug() message and then running with --verbose to see what&apos;s going on one way or another; feel free to post the log or email it to me for help debugging it.

Alright, will do.

&gt; &gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:72
&gt; &gt; +        self._worker_number = worker_number
&gt; 
&gt; Do you need self._worker_number? I don&apos;t see it being used anywhere.

Nope, leftover from another iteration!</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>418010</commentid>
    <comment_count>12</comment_count>
      <attachid>96588</attachid>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-09 07:35:52 -0700</bug_when>
    <thetext>Created attachment 96588
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>418011</commentid>
    <comment_count>13</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-09 07:36:45 -0700</bug_when>
    <thetext>(In reply to comment #12)
&gt; Created an attachment (id=96588) [details]
&gt; Patch

Cannot reproduce anymore the bug with the Xvfb servers not being killed on Ctrl-C, so I guess my script was buggy when that happened. Sorry for the noise.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>428537</commentid>
    <comment_count>14</comment_count>
      <attachid>96588</attachid>
    <who name="Adam Barth">abarth</who>
    <bug_when>2011-06-27 18:15:12 -0700</bug_when>
    <thetext>Comment on attachment 96588
Patch

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

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:51
&gt; +            &quot;DumpRenderTree&quot;, self.cmd_line(), environment)

&quot;DumpRenderTree&quot; should probably self._port.driver_name() since you&apos;ll want to support WebKit2.

&gt; Tools/Scripts/webkitpy/layout_tests/port/gtk.py:67
&gt; +        &quot;&quot;&quot;Starts a new Driver and returns a handle to it.&quot;&quot;&quot;

I&apos;d get rid of this docstring.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>429799</commentid>
    <comment_count>15</comment_count>
      <attachid>96588</attachid>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-29 12:47:34 -0700</bug_when>
    <thetext>Comment on attachment 96588
Patch

Landed with requested changes as r90036</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>429800</commentid>
    <comment_count>16</comment_count>
    <who name="Xan Lopez">xan.lopez</who>
    <bug_when>2011-06-29 12:47:52 -0700</bug_when>
    <thetext>All patches landed, closing.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>96434</attachid>
            <date>2011-06-08 09:33:04 -0700</date>
            <delta_ts>2011-06-09 07:35:45 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-57640-20110608183256.patch</filename>
            <type>text/plain</type>
            <size>2923</size>
            <attacher name="Xan Lopez">xan.lopez</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogODgzMzcKZGlmZiAtLWdpdCBhL1Rvb2xzL0NoYW5nZUxvZyBi
L1Rvb2xzL0NoYW5nZUxvZwppbmRleCAzOWY5N2U1MzhlOTljMzYxNjZjZmRlYTcyYjE2ZmIwZTgz
Y2U3NWIzLi4wNmIyN2VjZjM3YTJhZmE0NmFiZmY0NGZkMTVhMzMzYjY4YWRjOGRhIDEwMDY0NAot
LS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUg
QEAKKzIwMTEtMDYtMDggIFhhbiBMb3BleiAgPHhsb3BlekBpZ2FsaWEuY29tPgorCisgICAgICAg
IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFtHVEtdIG92ZXJsYXBwaW5n
IGRyYWcmZHJvcCB0ZXN0cyBmYWlsIG9uIE5SV1QKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtp
dC5vcmcvc2hvd19idWcuY2dpP2lkPTU3NjQwCisKKyAgICAgICAgTWFrZSBhIEdUSyB0ZXN0IGRy
aXZlciB0aGF0IHNwYXducyBvbmUgWHZmYiBpbnN0YW5jZSBwZXIKKyAgICAgICAgdGhyZWFkLiBU
aGlzIGF2b2lkcyBiYWQgaW50ZXJhY3Rpb25zIGluIERuRCB0ZXN0cyBiZXR3ZWVuIHRocmVhZHMu
CisKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9wb3J0L2d0ay5weToK
KwogMjAxMS0wNi0wOCAgSWx5YSBTaGVybWFuICA8aXNoZXJtYW5AY2hyb21pdW0ub3JnPgogCiAg
ICAgICAgIFJldmlld2VkIGJ5IEFuZHJlYXMgS2xpbmcuCmRpZmYgLS1naXQgYS9Ub29scy9TY3Jp
cHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9wb3J0L2d0ay5weSBiL1Rvb2xzL1NjcmlwdHMvd2Vi
a2l0cHkvbGF5b3V0X3Rlc3RzL3BvcnQvZ3RrLnB5CmluZGV4IGQ1N2JhN2MyZmZjMGU4YjA1MDk4
NGYyMzNjOGRkMDViYWMzMTNiYTEuLjdiMDQxMWYwMmVjOGVjZjVkM2QwM2RjYzdiN2ExYjc3NzQx
M2FlMjcgMTAwNjQ0Ci0tLSBhL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvbGF5b3V0X3Rlc3RzL3Bv
cnQvZ3RrLnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvbGF5b3V0X3Rlc3RzL3BvcnQv
Z3RrLnB5CkBAIC0zMSwxMSArMzEsMzQgQEAKIGltcG9ydCBsb2dnaW5nCiBpbXBvcnQgb3MKIGlt
cG9ydCBzaWduYWwKK2ltcG9ydCBzdWJwcm9jZXNzCiAKLWZyb20gd2Via2l0cHkubGF5b3V0X3Rl
c3RzLnBvcnQud2Via2l0IGltcG9ydCBXZWJLaXRQb3J0Citmcm9tIHdlYmtpdHB5LmxheW91dF90
ZXN0cy5wb3J0IGltcG9ydCBiYXNlLCBidWlsZGVycywgc2VydmVyX3Byb2Nlc3MKK2Zyb20gd2Vi
a2l0cHkubGF5b3V0X3Rlc3RzLnBvcnQud2Via2l0IGltcG9ydCBXZWJLaXRQb3J0LCBXZWJLaXRE
cml2ZXIKIAogX2xvZyA9IGxvZ2dpbmcuZ2V0TG9nZ2VyKCJ3ZWJraXRweS5sYXlvdXRfdGVzdHMu
cG9ydC5ndGsiKQogCitjbGFzcyBHdGtEcml2ZXIoV2ViS2l0RHJpdmVyKToKKyAgICAiIiJXZWJL
aXQgR3RrIGltcGxlbWVudGF0aW9uIG9mIHRoZSBEcml2ZXIgY2xhc3MuIiIiCisKKyAgICBkZWYg
X19pbml0X18oc2VsZiwgcG9ydCwgd29ya2VyX251bWJlcik6CisgICAgICAgIFdlYktpdERyaXZl
ci5fX2luaXRfXyhzZWxmLCBwb3J0LCB3b3JrZXJfbnVtYmVyKQorICAgICAgICBzZWxmLl9wcm9j
ZXNzID0gTm9uZQorCisgICAgZGVmIHN0YXJ0KHNlbGYpOgorICAgICAgICBydW5feHZmYiA9IFsi
WHZmYiIsICI6JWQiICUgKHNlbGYuX3dvcmtlcl9udW1iZXIgKyAxKV0KKyAgICAgICAgc2VsZi5f
cHJvY2VzcyA9IHN1YnByb2Nlc3MuUG9wZW4ocnVuX3h2ZmIpCisgICAgICAgIGVudmlyb25tZW50
ID0gc2VsZi5fcG9ydC5zZXR1cF9lbnZpcm9uX2Zvcl9zZXJ2ZXIoKQorICAgICAgICBlbnZpcm9u
bWVudFsnRFlMRF9GUkFNRVdPUktfUEFUSCddID0gc2VsZi5fcG9ydC5fYnVpbGRfcGF0aCgpCisg
ICAgICAgIGVudmlyb25tZW50WydEVU1QUkVOREVSVFJFRV9URU1QJ10gPSBzdHIoc2VsZi5fZHJp
dmVyX3RlbXBkaXIpCisgICAgICAgIGVudmlyb25tZW50WydESVNQTEFZJ10gPSAiOiVkIiAlIChz
ZWxmLl93b3JrZXJfbnVtYmVyICsgMSkKKyAgICAgICAgc2VsZi5fc2VydmVyX3Byb2Nlc3MgPSBz
ZXJ2ZXJfcHJvY2Vzcy5TZXJ2ZXJQcm9jZXNzKHNlbGYuX3BvcnQsCisgICAgICAgICAgICAiRHVt
cFJlbmRlclRyZWUiLCBzZWxmLmNtZF9saW5lKCksIGVudmlyb25tZW50KQorCisgICAgZGVmIHN0
b3Aoc2VsZik6CisgICAgICAgIFdlYktpdERyaXZlci5zdG9wKHNlbGYpCisgICAgICAgIG9zLmtp
bGwoc2VsZi5fcHJvY2Vzcy5waWQsIHNpZ25hbC5TSUdURVJNKQorICAgICAgICBzZWxmLl9wcm9j
ZXNzLndhaXQoKQogCiBjbGFzcyBHdGtQb3J0KFdlYktpdFBvcnQpOgogICAgICIiIldlYktpdCBH
dGsgaW1wbGVtZW50YXRpb24gb2YgdGhlIFBvcnQgY2xhc3MuIiIiCkBAIC00NCw2ICs2NywxMSBA
QCBjbGFzcyBHdGtQb3J0KFdlYktpdFBvcnQpOgogICAgICAgICBrd2FyZ3Muc2V0ZGVmYXVsdCgn
cG9ydF9uYW1lJywgJ2d0aycpCiAgICAgICAgIFdlYktpdFBvcnQuX19pbml0X18oc2VsZiwgKipr
d2FyZ3MpCiAKKyAgICBkZWYgY3JlYXRlX2RyaXZlcihzZWxmLCB3b3JrZXJfbnVtYmVyKToKKyAg
ICAgICAgIiIiU3RhcnRzIGEgbmV3IERyaXZlciBhbmQgcmV0dXJucyBhIGhhbmRsZSB0byBpdC4i
IiIKKyAgICAgICAgc2VsZi5fd29ya2VyX251bWJlciA9IHdvcmtlcl9udW1iZXIKKyAgICAgICAg
cmV0dXJuIEd0a0RyaXZlcihzZWxmLCB3b3JrZXJfbnVtYmVyKQorCiAgICAgZGVmIF9wYXRoX3Rv
X2FwYWNoZV9jb25maWdfZmlsZShzZWxmKToKICAgICAgICAgIyBGSVhNRTogVGhpcyBuZWVkcyB0
byBkZXRlY3QgdGhlIGRpc3RyaWJ1dGlvbiBhbmQgY2hhbmdlIGNvbmZpZyBmaWxlcy4KICAgICAg
ICAgcmV0dXJuIHNlbGYuX2ZpbGVzeXN0ZW0uam9pbihzZWxmLmxheW91dF90ZXN0c19kaXIoKSwg
J2h0dHAnLCAnY29uZicsCg==
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>96588</attachid>
            <date>2011-06-09 07:35:52 -0700</date>
            <delta_ts>2011-06-29 12:47:34 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-57640-20110609163545.patch</filename>
            <type>text/plain</type>
            <size>2577</size>
            <attacher name="Xan Lopez">xan.lopez</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogODg0NDQKZGlmZiAtLWdpdCBhL1Rvb2xzL0NoYW5nZUxvZyBi
L1Rvb2xzL0NoYW5nZUxvZwppbmRleCA2NjRiNDc1NDlmMWQ0MmM3YjkyMzUyNWRhZTczNWQxOWQ3
ZTE3NmNmLi4zNTQ1YjZhNzI3ZGMxNTcwOWNlZjYzYzA2N2EwMjgxYmFjY2FkODM5IDEwMDY0NAot
LS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUg
QEAKKzIwMTEtMDYtMDkgIFhhbiBMb3BleiAgPHhsb3BlekBpZ2FsaWEuY29tPgorCisgICAgICAg
IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFtHVEtdIG92ZXJsYXBwaW5n
IGRyYWcmZHJvcCB0ZXN0cyBmYWlsIG9uIE5SV1QKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtp
dC5vcmcvc2hvd19idWcuY2dpP2lkPTU3NjQwCisKKyAgICAgICAgTWFrZSBhIEdUSyB0ZXN0IGRy
aXZlciB0aGF0IHNwYXducyBvbmUgWHZmYiBpbnN0YW5jZSBwZXIKKyAgICAgICAgdGhyZWFkLiBU
aGlzIGF2b2lkcyBiYWQgaW50ZXJhY3Rpb25zIGluIERuRCB0ZXN0cyBiZXR3ZWVuIHRocmVhZHMu
CisKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9wb3J0L2d0ay5weToK
KwogMjAxMS0wNi0wOSAgRXJpYyBTZWlkZWwgIDxlcmljQHdlYmtpdC5vcmc+CiAKICAgICAgICAg
UmV2aWV3ZWQgYnkgQWRhbSBCYXJ0aC4KZGlmZiAtLWdpdCBhL1Rvb2xzL1NjcmlwdHMvd2Via2l0
cHkvbGF5b3V0X3Rlc3RzL3BvcnQvZ3RrLnB5IGIvVG9vbHMvU2NyaXB0cy93ZWJraXRweS9sYXlv
dXRfdGVzdHMvcG9ydC9ndGsucHkKaW5kZXggZDU3YmE3YzJmZmMwZThiMDUwOTg0ZjIzM2M4ZGQw
NWJhYzMxM2JhMS4uMWJlNGU3NTNmNWFjNGFjMTU0MDFjOWIyNzk1MDZlNTA2ZmY2YjRhNCAxMDA2
NDQKLS0tIGEvVG9vbHMvU2NyaXB0cy93ZWJraXRweS9sYXlvdXRfdGVzdHMvcG9ydC9ndGsucHkK
KysrIGIvVG9vbHMvU2NyaXB0cy93ZWJraXRweS9sYXlvdXRfdGVzdHMvcG9ydC9ndGsucHkKQEAg
LTMxLDE4ICszMSw0MSBAQAogaW1wb3J0IGxvZ2dpbmcKIGltcG9ydCBvcwogaW1wb3J0IHNpZ25h
bAoraW1wb3J0IHN1YnByb2Nlc3MKIAotZnJvbSB3ZWJraXRweS5sYXlvdXRfdGVzdHMucG9ydC53
ZWJraXQgaW1wb3J0IFdlYktpdFBvcnQKK2Zyb20gd2Via2l0cHkubGF5b3V0X3Rlc3RzLnBvcnQg
aW1wb3J0IGJhc2UsIGJ1aWxkZXJzLCBzZXJ2ZXJfcHJvY2Vzcywgd2Via2l0CiAKIF9sb2cgPSBs
b2dnaW5nLmdldExvZ2dlcigid2Via2l0cHkubGF5b3V0X3Rlc3RzLnBvcnQuZ3RrIikKIAogCi1j
bGFzcyBHdGtQb3J0KFdlYktpdFBvcnQpOgorY2xhc3MgR3RrRHJpdmVyKHdlYmtpdC5XZWJLaXRE
cml2ZXIpOgorICAgICIiIldlYktpdCBHdGsgaW1wbGVtZW50YXRpb24gb2YgdGhlIERyaXZlciBj
bGFzcy4iIiIKKworICAgIGRlZiBzdGFydChzZWxmKToKKyAgICAgICAgZGlzcGxheV9pZCA9IHNl
bGYuX3dvcmtlcl9udW1iZXIgKyAxCisgICAgICAgIHJ1bl94dmZiID0gWyJYdmZiIiwgIjolZCIg
JSAoZGlzcGxheV9pZCldCisgICAgICAgIHNlbGYuX3h2ZmJfcHJvY2VzcyA9IHN1YnByb2Nlc3Mu
UG9wZW4ocnVuX3h2ZmIpCisgICAgICAgIGVudmlyb25tZW50ID0gc2VsZi5fcG9ydC5zZXR1cF9l
bnZpcm9uX2Zvcl9zZXJ2ZXIoKQorICAgICAgICBlbnZpcm9ubWVudFsnRElTUExBWSddID0gIjol
ZCIgJSAoZGlzcGxheV9pZCkKKyAgICAgICAgc2VsZi5fc2VydmVyX3Byb2Nlc3MgPSBzZXJ2ZXJf
cHJvY2Vzcy5TZXJ2ZXJQcm9jZXNzKHNlbGYuX3BvcnQsCisgICAgICAgICAgICAiRHVtcFJlbmRl
clRyZWUiLCBzZWxmLmNtZF9saW5lKCksIGVudmlyb25tZW50KQorCisgICAgZGVmIHN0b3Aoc2Vs
Zik6CisgICAgICAgIHdlYmtpdC5XZWJLaXREcml2ZXIuc3RvcChzZWxmKQorICAgICAgICBvcy5r
aWxsKHNlbGYuX3h2ZmJfcHJvY2Vzcy5waWQsIHNpZ25hbC5TSUdURVJNKQorICAgICAgICBzZWxm
Ll94dmZiX3Byb2Nlc3Mud2FpdCgpCisKKworY2xhc3MgR3RrUG9ydCh3ZWJraXQuV2ViS2l0UG9y
dCk6CiAgICAgIiIiV2ViS2l0IEd0ayBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgUG9ydCBjbGFzcy4i
IiIKIAogICAgIGRlZiBfX2luaXRfXyhzZWxmLCAqKmt3YXJncyk6CiAgICAgICAgIGt3YXJncy5z
ZXRkZWZhdWx0KCdwb3J0X25hbWUnLCAnZ3RrJykKLSAgICAgICAgV2ViS2l0UG9ydC5fX2luaXRf
XyhzZWxmLCAqKmt3YXJncykKKyAgICAgICAgd2Via2l0LldlYktpdFBvcnQuX19pbml0X18oc2Vs
ZiwgKiprd2FyZ3MpCisKKyAgICBkZWYgY3JlYXRlX2RyaXZlcihzZWxmLCB3b3JrZXJfbnVtYmVy
KToKKyAgICAgICAgIiIiU3RhcnRzIGEgbmV3IERyaXZlciBhbmQgcmV0dXJucyBhIGhhbmRsZSB0
byBpdC4iIiIKKyAgICAgICAgcmV0dXJuIEd0a0RyaXZlcihzZWxmLCB3b3JrZXJfbnVtYmVyKQog
CiAgICAgZGVmIF9wYXRoX3RvX2FwYWNoZV9jb25maWdfZmlsZShzZWxmKToKICAgICAgICAgIyBG
SVhNRTogVGhpcyBuZWVkcyB0byBkZXRlY3QgdGhlIGRpc3RyaWJ1dGlvbiBhbmQgY2hhbmdlIGNv
bmZpZyBmaWxlcy4K
</data>

          </attachment>
      

    </bug>

</bugzilla>