<?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>22929</bug_id>
          
          <creation_ts>2008-12-18 20:46:48 -0800</creation_ts>
          <short_desc>Memory Regression from r39309</short_desc>
          <delta_ts>2009-01-08 17:52:20 -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>Images</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Mac</rep_platform>
          <op_sys>OS X 10.5</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc>http://www.vodcars.com</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar, Regression</keywords>
          <priority>P1</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Stephanie Lewis">slewis</reporter>
          <assigned_to name="Peter Kasting">pkasting</assigned_to>
          <cc>hyatt</cc>
    
    <cc>mitz</cc>
    
    <cc>pkasting</cc>
    
    <cc>sam</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>102959</commentid>
    <comment_count>0</comment_count>
    <who name="Stephanie Lewis">slewis</who>
    <bug_when>2008-12-18 20:46:48 -0800</bug_when>
    <thetext>patch http://trac.webkit.org/changeset/39309 caused a memory regression on the mozilla membuster tests.  The specific site with the regression is www.vodcars.com.  After loading the site RSIZE jumps 10-15 MB.  

This message is also printed to the terminal several times:
Thu Dec 18 20:33:36 slewis.apple.com Safari[42802] &lt;Error&gt;: CGImageSourceUpdateData image source was already finalized

&lt;rdar://problem/6457900&gt; REGRESSION: Memory regression loading www.vodcars.com</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>102984</commentid>
    <comment_count>1</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-19 08:51:08 -0800</bug_when>
    <thetext>That error message seems strange.  I will try and take a first look at this, may need Hyatt&apos;s eyes too.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>102992</commentid>
    <comment_count>2</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-19 09:26:59 -0800</bug_when>
    <thetext>I bet I know what this is, or at least part of it.  Now that we&apos;re not deleting the whole decoder after every frame, we shouldn&apos;t be calling setData() on it either.  I haven&apos;t had time to test the effect of removing this yet (typing this on my phone) and don&apos;t know how to run the memory test locally anyway, but I bet this will solve it.

I also suspect this may help rid the CG decoder of some of the perf issues I still hadn&apos;t figured out, since setData() resets the whole decoder state.

Will whip up a patch when I get into the office in half an hour.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103002</commentid>
    <comment_count>3</comment_count>
      <attachid>26148</attachid>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-19 10:56:29 -0800</bug_when>
    <thetext>Created attachment 26148
patch v1

This ought to fix the error message, and if the memory regression is caused by the same problem it should fix that too.  I&apos;m not sure how to test that locally so I&apos;ll be interested in the performance of this in the test suite.

In short, the issue was that in the old code, we always deleted the decoder, so we always called setData() after it.  Now that we don&apos;t delete the decoder all the time, we shouldn&apos;t always call setData() again either.  Because BitmapImage seems like the wrong place to know how ImageSource is handling a clear() call internally, I moved this logic into ImageSource::clear() itself.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103062</commentid>
    <comment_count>4</comment_count>
    <who name="Stephanie Lewis">slewis</who>
    <bug_when>2008-12-19 22:01:35 -0800</bug_when>
    <thetext>The patch cleared up the error, but not the memory regression.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103236</commentid>
    <comment_count>5</comment_count>
      <attachid>26216</attachid>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-22 15:45:59 -0800</bug_when>
    <thetext>Created attachment 26216
patch v2

That&apos;s depressing.

OK, this patch goes one small step further by reverting the CG ImageSource to its former behavior of destroying the decoder after every large frame.  This should fix the memory issues (please verify).

I&apos;m not totally sure why this is necessary.  On the images I looked at it looked as if the CG decoders were dropping frames that no one referenced (in fact, so aggressively that they continued to redecode frames unnecessarily).  But I don&apos;t have the CG source code so I can&apos;t look into this or implement a &quot;drop unnecessary frames&quot; call like the other platforms now have, which is IMO the correct way to address this issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103299</commentid>
    <comment_count>6</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-23 08:46:32 -0800</bug_when>
    <thetext>I just realized this doesn&apos;t quite revert to the previous behavior.  It&apos;s actually more aggressive than that -- it destroys the decoder even when we were merely invalidating the last frame because we&apos;d gotten new data.  Not sure how big of a problem that is.  I&apos;m inclined to not worry about it unless it actually leads to CPU usage problems, since solving that issue alone will require yet more hacks; the &quot;right&quot; solution (IMO), to implement selective destruction of frames like the other platforms, ought to take care of this too.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103433</commentid>
    <comment_count>7</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-25 23:15:22 -0800</bug_when>
    <thetext>Also, note that checking this in will re-cause bug 22108 :(

/cue expletives</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103515</commentid>
    <comment_count>8</comment_count>
      <attachid>26216</attachid>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-26 19:50:09 -0800</bug_when>
    <thetext>Comment on attachment 26216
patch v2

Clearing r? on this, I&apos;m not willing to regress another bug to fix this one.  We should try and get the first patch in at least since it&apos;s an unqualified win, and then figure out what the memory usage here is actually caused by.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103719</commentid>
    <comment_count>9</comment_count>
    <who name="">mitz</who>
    <bug_when>2008-12-29 12:41:14 -0800</bug_when>
    <thetext>ObjectAlloc shows many more live CGImages due to r39309. They are held by the CGImageSource. Prior to r39309, ImageSource::clear() always released the CGImageSource, which led to the CGImages being destroyed.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>103751</commentid>
    <comment_count>10</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2008-12-29 17:36:42 -0800</bug_when>
    <thetext>Yes.  Normally both the CGImageSource and the BitmapImage hold references to CGImages.  BitmapImage is designed to release its references for large images, and tell the CGImageSource it can do the same.  Unfortunately there&apos;s currently no API (that I know of) to tell the CGImageSource that it can release certain frames selectively, and it seems to be overly aggressive about hanging onto everything even when no one else has a ref, so the old code forcibly destroyed it to keep memory usage low.  Unfortunately this trashes other useful data like repeat counts, leading to problems with animated images.

The best solution is to find some way to communicate which frames can be released, a la the public GIFImageDecoder.cpp.  Another possibility is to try to return to a hack like the old code and yet still preserve metadata like the repeat count on the side in order to avoid regressing issue 22108; this is a lot more fragile.

Finally, in fairness to the CGImageSource, it&apos;s not totally clear to me that it&apos;s always wasting memory in what images it holds references to.  Perhaps in some cases it&apos;s holding onto prior frames to prevent redecoding, which means that it would use more memory now, but legitimately so (i.e. this is an intentional &quot;regression&quot; in memory usage in a few cases in order to save CPU and gain correctness).  OTOH, testing seems to show that the CGImageSource decodes too frequently anyway, so if this is the reason, then the code isn&apos;t very good.

I need someone with access to the closed source decoders, like Hyatt, to help solve this problem.  I have no visibility into the decoder :(</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104211</commentid>
    <comment_count>11</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2009-01-02 19:52:49 -0800</bug_when>
    <thetext>This memory use regression is far more serious than the original problem in terms of effect on Safari. That problem meant that certain GIFs wouldn&apos;t animate, but this causes memory leaks and makes the browser slower and slower over time.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104457</commentid>
    <comment_count>12</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-05 11:36:11 -0800</bug_when>
    <thetext>I don&apos;t see any memory leaks here.  There may be increased memory usage for certain GIFs but AFAIK no leaks (which would worry me very much).  Am I missing something?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104615</commentid>
    <comment_count>13</comment_count>
    <who name="Maciej Stachowiak">mjs</who>
    <bug_when>2009-01-06 13:29:46 -0800</bug_when>
    <thetext>The patch does not cause memory leaks, jut a very large memory use regression. The mozilla membuster test is one of the primary benchmarks we are tracking for memory use. The memory regression needs to be fixed soon, or the original patch will need to be reverted. We can&apos;t have a huge memory regression in the tree for this long.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104651</commentid>
    <comment_count>14</comment_count>
    <who name="Sam Weinig">sam</who>
    <bug_when>2009-01-06 15:16:29 -0800</bug_when>
    <thetext>What information do you feel you are missing that you could gather from looking at the CG sources?  Perhaps I can help. </thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104672</commentid>
    <comment_count>15</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-06 16:39:58 -0800</bug_when>
    <thetext>Basically, I need to understand the criteria it uses to decide how to hold references to frames, so that I can understand
(a) Which frames are getting held here that weren&apos;t before,
(b) Whether that&apos;s actually accruing any advantage to the decoder (i.e. is this a pure regression, or is this a tradeoff?), and
(c) How I can ask the decoder to release frames -- especially to release frames selectively a la the interface that got added recently (see the open-source GIFImageDecoder.cpp code).

The dumbest thing for the decoder to do would be to just always hold refs to all frames, and not have any API to release them.  Better would be either a smart algorithm that drops references unless they&apos;re really needed, or an API that callers can use to instruct the decoder to drop refs, or even better, both.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104736</commentid>
    <comment_count>16</comment_count>
    <who name="">mitz</who>
    <bug_when>2009-01-07 11:22:37 -0800</bug_when>
    <thetext>(In reply to comment #15)
&gt; (c) How I can ask the decoder to release frames -- especially to release frames
&gt; selectively a la the interface that got added recently (see the open-source
&gt; GIFImageDecoder.cpp code).

ImageIO does not have API or any other way that I could see to selectively release images that a CGImageSource has retained. The way to release those images is to release the CGImageSource. That is what the code used to do prior to r39309, and I strongly recommend going back to that behavior.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104738</commentid>
    <comment_count>17</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-07 11:28:57 -0800</bug_when>
    <thetext>OK, but _why_ has it retained these images?  It clearly doesn&apos;t retain all the images all the time -- most of the time, it discards them.  Why does it retain the ones on this particular site?  Everyone keeps assuming this is just completely wasted memory, but that&apos;s not obvious to me until I understand what&apos;s different about this case than the common ones.

If I simply revert r39309, I&apos;ll break animation in a lot of cases, since the old code destroyed the repeat count.  Instead, if we want to go back to the solution of destroying the whole decoder, we&apos;re going to need to put more complex logic into caching this value inside the ImageSource.  I can probably try to write up such a patch.  Can someone please review the patch that&apos;s already on this bug, though?

Has anyone given any thought to simply using the open-source GIF decoder?  At this point it is significantly faster and uses less memory than the GIF decoder in ImageIO.  I have been operating under the assumption that this suggestion wouldn&apos;t even be considered, but it seems worth making.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104774</commentid>
    <comment_count>18</comment_count>
    <who name="Sam Weinig">sam</who>
    <bug_when>2009-01-07 13:49:28 -0800</bug_when>
    <thetext>(In reply to comment #17)
&gt; OK, but _why_ has it retained these images?  It clearly doesn&apos;t retain all the
&gt; images all the time -- most of the time, it discards them. 

What makes you say this?  From the source, it looks like the only time it discards images is when the CGImageSource is destroyed.

&gt; ... Why does it retain
&gt; the ones on this particular site?  Everyone keeps assuming this is just
&gt; completely wasted memory, but that&apos;s not obvious to me until I understand
&gt; what&apos;s different about this case than the common ones.

We are not looking to justify an increase in memory use, we are trying to fix a regression.      

&gt; If I simply revert r39309, I&apos;ll break animation in a lot of cases, since the
&gt; old code destroyed the repeat count.

Broken animations were an earlier regression. Before that, we had no significant issues in this area.

&gt; Instead, if we want to go back to the
&gt; solution of destroying the whole decoder, we&apos;re going to need to put more
&gt; complex logic into caching this value inside the ImageSource.

Alternatively, we can consider reverting more of the changes that led up to the regression r39309 was meant to solve.

&gt;  I can probably
&gt; try to write up such a patch.  Can someone please review the patch that&apos;s
&gt; already on this bug, though?

That patch does not address the memory issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104781</commentid>
    <comment_count>19</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-07 14:10:48 -0800</bug_when>
    <thetext>(In reply to comment #18)
&gt; (In reply to comment #17)
&gt; &gt; OK, but _why_ has it retained these images?  It clearly doesn&apos;t retain all the
&gt; &gt; images all the time -- most of the time, it discards them. 
&gt; 
&gt; What makes you say this?  From the source, it looks like the only time it
&gt; discards images is when the CGImageSource is destroyed.

That&apos;s strange.  That ought to mean that not destroying the CGImageSource regresses the memory usage for any &quot;large&quot; GIF (where &quot;large&quot; means &quot;big enough decoded size to trip the heuristics in the old code&quot;).  But on most of my test images I see no real difference in memory usage in Safari for Windows.  Also, for very large images, we ought to see memory usage growing accordingly as the image frames are decoded, which is precisely the behavior I could reproduce on the Cairo/Chromium builds when I tested taking out all frame-freeing entirely.  But instead memory usage on these images seems capped.  I don&apos;t know how to square all of this with your examination of the source code :(

&gt; &gt; ... Why does it retain
&gt; &gt; the ones on this particular site?  Everyone keeps assuming this is just
&gt; &gt; completely wasted memory, but that&apos;s not obvious to me until I understand
&gt; &gt; what&apos;s different about this case than the common ones.
&gt; 
&gt; We are not looking to justify an increase in memory use, we are trying to fix a
&gt; regression.

I&apos;m not denying memory usage has increased on this site.  I certainly want to fix that assuming it doesn&apos;t cause an even worse tradeoff.  I merely want to understand what that tradeoff is, if any.  The data looks odd and this code is hairy, and I&apos;d rather not cause an endless series of regressions by failing to completely understand what&apos;s going on.

&gt; &gt; If I simply revert r39309, I&apos;ll break animation in a lot of cases, since the
&gt; &gt; old code destroyed the repeat count.
&gt; 
&gt; Broken animations were an earlier regression. Before that, we had no
&gt; significant issues in this area.

Not true.  Safari has always suffered from major CPU usage issues decoding certain GIFs (which are fixed in Cairo/Chromium but not fixed in Safari, partly due to the lack of ability to tell the CG decoder to discard certain frames), and animated GIFs far too slowly (unboundedly slowly, actually), with GIFs taking anywhere between 10% to 200% longer to animate than they should have (an issue which _is_ fixed).  Additionally, the Cairo/Chromium ports suffered from unbounded memory usage (spikes of several hundred megs on large images), which is also fixed.  Image animations also didn&apos;t sync correctly across tab switching, scroll events, etc.; this is also fixed.

&gt; Alternatively, we can consider reverting more of the changes that led up to the
&gt; regression r39309 was meant to solve.

The only path backward is probably to back out everything all the way to the beginning, which would reintroduce all the problems I mentioned above.

&gt; &gt;  I can probably
&gt; &gt; try to write up such a patch.  Can someone please review the patch that&apos;s
&gt; &gt; already on this bug, though?
&gt; 
&gt; That patch does not address the memory issue.

But it _does_ address the other errors, is correct, and is a necessary precursor to the patch I plan to write to have CGImageSource.cpp destroy the decoder, since there seems to be no other way to release these image references.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104789</commentid>
    <comment_count>20</comment_count>
    <who name="Sam Weinig">sam</who>
    <bug_when>2009-01-07 14:27:20 -0800</bug_when>
    <thetext>&gt; But it _does_ address the other errors, is correct, and is a necessary
&gt; precursor to the patch I plan to write to have CGImageSource.cpp destroy the
&gt; decoder, since there seems to be no other way to release these image
&gt; references.

This regression has been in the tree long enough at this time that unless you are certain you can fix this issue in the next few days we really will want to roll out the series of patches that lead up to here.  For that reason, I not sure it makes sense land additional partial fixes on top of it. </thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104795</commentid>
    <comment_count>21</comment_count>
      <attachid>26148</attachid>
    <who name="Sam Weinig">sam</who>
    <bug_when>2009-01-07 15:27:35 -0800</bug_when>
    <thetext>Comment on attachment 26148
patch v1

After hearing from Peter that he thinks he can fix the memory regression in a timely manner (end of the week?) I am going to r+ this.  The changelog needs to be changed to note that it does not actually fix the regression.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104807</commentid>
    <comment_count>22</comment_count>
      <attachid>26148</attachid>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-07 16:28:07 -0800</bug_when>
    <thetext>Comment on attachment 26148
patch v1

Clearing review flag to keep this patch off the &quot;waiting for commit&quot; list&quot;, since I&apos;ve landed this patch but am not yet closing the bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104955</commentid>
    <comment_count>23</comment_count>
      <attachid>26542</attachid>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-08 16:01:07 -0800</bug_when>
    <thetext>Created attachment 26542
memory regression patch v1

My fix for bug 22108 was helpful for non-CG backends, but with further testing looks to have been totally useless for CG, which apparently scans as much of the GIF as it needs to determine the repetition count.  Since that&apos;s true, it won&apos;t make animation any flakier to go ahead and destroy the decoder after each frame if the image is large.

In theory, the CG decoder could use the images it&apos;s reffed to speed decoding of later frames, which means this would trade off lower memory usage for higher CPU usage; and if the decoder wasn&apos;t extremely aggressive about throwing away frames internally during decoding, even the memory savings wouldn&apos;t be true savings, as transiently memory would spike that high anyway.  However, the CG decoder doesn&apos;t seem to use these frames that way, so keeping them doesn&apos;t save anything.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104968</commentid>
    <comment_count>24</comment_count>
      <attachid>26542</attachid>
    <who name="Sam Weinig">sam</who>
    <bug_when>2009-01-08 16:51:47 -0800</bug_when>
    <thetext>Comment on attachment 26542
memory regression patch v1

This does indeed address the memory issue. Thanks for tracking this down. r=me.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>104979</commentid>
    <comment_count>25</comment_count>
    <who name="Peter Kasting">pkasting</who>
    <bug_when>2009-01-08 17:52:20 -0800</bug_when>
    <thetext>Fixed in r39734.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>26148</attachid>
            <date>2008-12-19 10:56:29 -0800</date>
            <delta_ts>2009-01-07 16:28:07 -0800</delta_ts>
            <desc>patch v1</desc>
            <filename>patch</filename>
            <type>text/plain</type>
            <size>7821</size>
            <attacher name="Peter Kasting">pkasting</attacher>
            
              <data encoding="base64">SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n
CShyZXZpc2lvbiAzOTQwOCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMjggQEAKKzIwMDgtMTItMTkgIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n
bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg
IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjkyOQorCisgICAgICAg
IEF0dGVtcHQgdG8gZml4IG1lbW9yeSByZWdyZXNzaW9uIGJ5IG5vdCBjYWxsaW5nIHNldERhdGEo
KSByZXBlYXRlZGx5CisgICAgICAgIHdoZW4gaXQncyBub3QgbmVjZXNzYXJ5LiAgUHVzaGVzIHRo
ZSByZXNwb25zaWJpbGl0eSBmb3IgY2FsbGluZworICAgICAgICBzZXREYXRhKCkgYWZ0ZXIgY2xl
YXIoKSBpbnRvIHRoZSBJbWFnZVNvdXJjZSB3aGljaCBwcmVzdW1hYmx5IGtub3dzCisgICAgICAg
IGJldHRlciB0aGFuIEJpdG1hcEltYWdlIHdoYXQgbmVlZHMgdG8gYmUgZG9uZS4KKworICAgICAg
ICAqIHBsYXRmb3JtL2dyYXBoaWNzL0JpdG1hcEltYWdlLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6
OkJpdG1hcEltYWdlOjpkZXN0cm95RGVjb2RlZERhdGEpOgorICAgICAgICAqIHBsYXRmb3JtL2dy
YXBoaWNzL0ltYWdlU291cmNlLmg6CisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2Fpcm8v
SW1hZ2VTb3VyY2VDYWlyby5jcHA6CisgICAgICAgIChXZWJDb3JlOjpJbWFnZVNvdXJjZTo6Y2xl
YXIpOgorICAgICAgICAqIHBsYXRmb3JtL2dyYXBoaWNzL2NnL0ltYWdlU291cmNlQ0cuY3BwOgor
ICAgICAgICAoV2ViQ29yZTo6SW1hZ2VTb3VyY2U6OmNsZWFyKToKKyAgICAgICAgKiBwbGF0Zm9y
bS9ncmFwaGljcy9xdC9JbWFnZVNvdXJjZVF0LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkltYWdl
U291cmNlOjp+SW1hZ2VTb3VyY2UpOgorICAgICAgICAoV2ViQ29yZTo6SW1hZ2VTb3VyY2U6OmNs
ZWFyKToKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy93eC9JbWFnZVNvdXJjZVd4LmNwcDoK
KyAgICAgICAgKFdlYkNvcmU6OkltYWdlU291cmNlOjp+SW1hZ2VTb3VyY2UpOgorICAgICAgICAo
V2ViQ29yZTo6SW1hZ2VTb3VyY2U6OmNsZWFyKToKKwogMjAwOC0xMi0xOSAgSG9sZ2VyIEhhbnMg
UGV0ZXIgRnJleXRoZXIgIDx6ZWNrZUBzZWxmaXNoLm9yZz4KIAogICAgICAgICBSZXZpZXdlZCBi
eSBTYW0gV2VpbmlnLgpJbmRleDogV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFn
ZS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFn
ZS5jcHAJKHJldmlzaW9uIDM5NDA3KQorKysgV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRt
YXBJbWFnZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTgwLDkgKzgwLDcgQEAgdm9pZCBCaXRtYXBJ
bWFnZTo6ZGVzdHJveURlY29kZWREYXRhKGJvbwogCiAgICAgZGVzdHJveU1ldGFkYXRhQW5kTm90
aWZ5KGZyYW1lc0NsZWFyZWQpOwogCi0gICAgbV9zb3VyY2UuY2xlYXIoZGVzdHJveUFsbCwgY2xl
YXJCZWZvcmVGcmFtZSk7Ci0gICAgaWYgKG1fZGF0YSkKLSAgICAgICAgbV9zb3VyY2Uuc2V0RGF0
YShtX2RhdGEuZ2V0KCksIG1fYWxsRGF0YVJlY2VpdmVkKTsKKyAgICBtX3NvdXJjZS5jbGVhcihk
ZXN0cm95QWxsLCBjbGVhckJlZm9yZUZyYW1lLCBtX2RhdGEuZ2V0KCksIG1fYWxsRGF0YVJlY2Vp
dmVkKTsKICAgICByZXR1cm47CiB9CiAKSW5kZXg6IFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3Mv
SW1hZ2VTb3VyY2UuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0lt
YWdlU291cmNlLmgJKHJldmlzaW9uIDM5NDA3KQorKysgV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGlj
cy9JbWFnZVNvdXJjZS5oCSh3b3JraW5nIGNvcHkpCkBAIC05OSw3ICs5OSwxNSBAQCBwdWJsaWM6
CiAgICAgLy8gQ2FsbGVycyBzaG91bGQgbm90IGNhbGwgY2xlYXIoZmFsc2UsIG4pIGFuZCBzdWJz
ZXF1ZW50bHkgY2FsbAogICAgIC8vIGNyZWF0ZUZyYW1lQXRJbmRleChtKSB3aXRoIG0gPCBuLCB1
bmxlc3MgdGhleSBmaXJzdCBjYWxsIGNsZWFyKHRydWUpLgogICAgIC8vIFRoaXMgZW5zdXJlcyB0
aGF0IHN0YXRlZnVsIEltYWdlU291cmNlcy9kZWNvZGVycyB3aWxsIHdvcmsgcHJvcGVybHkuCi0g
ICAgdm9pZCBjbGVhcihib29sIGRlc3Ryb3lBbGwsIHNpemVfdCBjbGVhckJlZm9yZUZyYW1lID0g
MCk7CisgICAgLy8KKyAgICAvLyBUaGUgfGRhdGF8IGFuZCB8YWxsRGF0YVJlY2VpdmVkfCBwYXJh
bWV0ZXJzIHNob3VsZCBiZSBzdXBwbGllZCBieSBjYWxsZXJzCisgICAgLy8gd2hvIHNldCB8ZGVz
dHJveUFsbHwgdG8gdHJ1ZSBpZiB0aGV5IHdpc2ggdG8gYmUgYWJsZSB0byBjb250aW51ZSB1c2lu
ZworICAgIC8vIHRoZSBJbWFnZVNvdXJjZS4gIFRoaXMgd2F5IGltcGxlbWVudGF0aW9ucyB3aGlj
aCBjaG9vc2UgdG8gZGVzdHJveSB0aGVpcgorICAgIC8vIGRlY29kZXJzIGluIHNvbWUgY2FzZXMg
Y2FuIHJlY29uc3RydWN0IHRoZW0gY29ycmVjdGx5LgorICAgIHZvaWQgY2xlYXIoYm9vbCBkZXN0
cm95QWxsLAorICAgICAgICAgICAgICAgc2l6ZV90IGNsZWFyQmVmb3JlRnJhbWUgPSAwLAorICAg
ICAgICAgICAgICAgU2hhcmVkQnVmZmVyKiBkYXRhID0gTlVMTCwKKyAgICAgICAgICAgICAgIGJv
b2wgYWxsRGF0YVJlY2VpdmVkID0gZmFsc2UpOwogCiAgICAgYm9vbCBpbml0aWFsaXplZCgpIGNv
bnN0OwogCkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2NhaXJvL0ltYWdlU291cmNl
Q2Fpcm8uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2Fpcm8v
SW1hZ2VTb3VyY2VDYWlyby5jcHAJKHJldmlzaW9uIDM5NDA3KQorKysgV2ViQ29yZS9wbGF0Zm9y
bS9ncmFwaGljcy9jYWlyby9JbWFnZVNvdXJjZUNhaXJvLmNwcAkod29ya2luZyBjb3B5KQpAQCAt
MTAwLDE2ICsxMDAsMTggQEAgSW1hZ2VTb3VyY2U6On5JbWFnZVNvdXJjZSgpCiAgICAgY2xlYXIo
dHJ1ZSk7CiB9CiAKLXZvaWQgSW1hZ2VTb3VyY2U6OmNsZWFyKGJvb2wgZGVzdHJveUFsbCwgc2l6
ZV90IGNsZWFyQmVmb3JlRnJhbWUpCit2b2lkIEltYWdlU291cmNlOjpjbGVhcihib29sIGRlc3Ry
b3lBbGwsIHNpemVfdCBjbGVhckJlZm9yZUZyYW1lLCBTaGFyZWRCdWZmZXIqIGRhdGEsIGJvb2wg
YWxsRGF0YVJlY2VpdmVkKQogewotICAgIGlmIChkZXN0cm95QWxsKSB7Ci0gICAgICAgIGRlbGV0
ZSBtX2RlY29kZXI7Ci0gICAgICAgIG1fZGVjb2RlciA9IDA7CisgICAgaWYgKCFkZXN0cm95QWxs
KSB7CisgICAgICAgIGlmIChtX2RlY29kZXIpCisgICAgICAgICAgICBtX2RlY29kZXItPmNsZWFy
RnJhbWVCdWZmZXJDYWNoZShjbGVhckJlZm9yZUZyYW1lKTsKICAgICAgICAgcmV0dXJuOwogICAg
IH0KIAotICAgIGlmIChtX2RlY29kZXIpCi0gICAgICAgIG1fZGVjb2Rlci0+Y2xlYXJGcmFtZUJ1
ZmZlckNhY2hlKGNsZWFyQmVmb3JlRnJhbWUpOworICAgIGRlbGV0ZSBtX2RlY29kZXI7CisgICAg
bV9kZWNvZGVyID0gMDsKKyAgICBpZiAoZGF0YSkKKyAgICAgIHNldERhdGEoZGF0YSwgYWxsRGF0
YVJlY2VpdmVkKTsKIH0KIAogYm9vbCBJbWFnZVNvdXJjZTo6aW5pdGlhbGl6ZWQoKSBjb25zdApJ
bmRleDogV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jZy9JbWFnZVNvdXJjZUNHLmNwcAo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2NnL0ltYWdlU291cmNlQ0cuY3Bw
CShyZXZpc2lvbiAzOTQwNykKKysrIFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2cvSW1hZ2VT
b3VyY2VDRy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTQ4LDIzICs0OCwyMyBAQCBJbWFnZVNvdXJj
ZTo6fkltYWdlU291cmNlKCkKICAgICBjbGVhcih0cnVlKTsKIH0KIAotdm9pZCBJbWFnZVNvdXJj
ZTo6Y2xlYXIoYm9vbCBkZXN0cm95QWxsLCBzaXplX3QgY2xlYXJCZWZvcmVGcmFtZSkKK3ZvaWQg
SW1hZ2VTb3VyY2U6OmNsZWFyKGJvb2wgZGVzdHJveUFsbCwgc2l6ZV90IGNsZWFyQmVmb3JlRnJh
bWUsIFNoYXJlZEJ1ZmZlciogZGF0YSwgYm9vbCBhbGxEYXRhUmVjZWl2ZWQpCiB7Ci0gICAgaWYg
KGRlc3Ryb3lBbGwpIHsKLSAgICAgICAgaWYgKG1fZGVjb2RlcikgewotICAgICAgICAgICAgQ0ZS
ZWxlYXNlKG1fZGVjb2Rlcik7Ci0gICAgICAgICAgICBtX2RlY29kZXIgPSAwOwotICAgICAgICB9
CisgICAgaWYgKCFkZXN0cm95QWxsKSB7CisgICAgICAgIC8vIFRPRE8ocGthc3RpbmcpOiBJZiB0
aGVyZSB3YXMgYW4gYXBwcm9wcmlhdGUgQVBJIHRvIGRvIHNvLCB3ZSBjb3VsZAorICAgICAgICAv
LyBleHBsaWNpdGx5IHRlbGwgdGhlIENHIGRlY29kZXIgaXQgY2FuIGRpc2NhcmQgZnJhbWVzIGJl
Zm9yZQorICAgICAgICAvLyB8Y2xlYXJCZWZvcmVGcmFtZXwgKG5vdCBpbmNsdWRpbmcgYW55dGhp
bmcgaXQgbmVlZHMgdG8ga2VlcCBhcm91bmQKKyAgICAgICAgLy8gbG9jYWxseSB0byBjb250aW51
ZSBkZWNvZGluZyBjb3JyZWN0bHkpLiAgVGhpcyBtaWdodCBoZWxwIHRoZSBkZWNvZGVyCisgICAg
ICAgIC8vIG9wdGltaXplIG1lbW9yeS9DUFUgdXNhZ2UuCiAgICAgICAgIHJldHVybjsKICAgICB9
CiAKLSAgICAvLyBUT0RPKHBrYXN0aW5nKTogSWYgdGhlcmUgd2FzIGFuIGFwcHJvcHJpYXRlIEFQ
SSB0byBkbyBzbywgd2UgY291bGQKLSAgICAvLyBleHBsaWNpdGx5IHRlbGwgdGhlIENHIGRlY29k
ZXIgaXQgY2FuIGRpc2NhcmQgZnJhbWVzIGJlZm9yZQotICAgIC8vIHxjbGVhckJlZm9yZUZyYW1l
fCAobm90IGluY2x1ZGluZyBhbnl0aGluZyBpdCBuZWVkcyB0byBrZWVwIGFyb3VuZAotICAgIC8v
IGxvY2FsbHkgdG8gY29udGludWUgZGVjb2RpbmcgY29ycmVjdGx5KS4gIFRoaXMgbWlnaHQgaGVs
cCB0aGUgZGVjb2RlcgotICAgIC8vIG9wdGltaXplIG1lbW9yeS9DUFUgdXNhZ2UuICBSaWdodCBu
b3cgdGhlIGRlY29kZXIgc2VlbXMgdG8gdGhyb3cgYXdheQotICAgIC8vIGZyYW1lcyBhZ2dyZXNz
aXZlbHkgYW5kIHRoZW4gcmUtZGVjb2RlIGZyb20gdGhlIGJlZ2lubmluZyBlYWNoIHRpbWUsIHRo
dXMKLSAgICAvLyB1c2luZyBtb3JlIENQVSB0aGFuIGl0IG5lZWRzIHRvLgorICAgIGlmIChtX2Rl
Y29kZXIpIHsKKyAgICAgICAgQ0ZSZWxlYXNlKG1fZGVjb2Rlcik7CisgICAgICAgIG1fZGVjb2Rl
ciA9IDA7CisgICAgfQorICAgIGlmIChkYXRhKQorICAgICAgc2V0RGF0YShkYXRhLCBhbGxEYXRh
UmVjZWl2ZWQpOwogfQogCiBDRkRpY3Rpb25hcnlSZWYgaW1hZ2VTb3VyY2VPcHRpb25zKCkKSW5k
ZXg6IFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvcXQvSW1hZ2VTb3VyY2VRdC5jcHAKPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9xdC9JbWFnZVNvdXJjZVF0LmNwcAko
cmV2aXNpb24gMzk0MDcpCisrKyBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL3F0L0ltYWdlU291
cmNlUXQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC00NSw3ICs0NSw3IEBAIEltYWdlU291cmNlOjpJ
bWFnZVNvdXJjZSgpCiAKIEltYWdlU291cmNlOjp+SW1hZ2VTb3VyY2UoKQogewotICAgIGRlbGV0
ZSBtX2RlY29kZXI7CisgICAgY2xlYXIodHJ1ZSk7CiB9CiAKIGJvb2wgSW1hZ2VTb3VyY2U6Omlu
aXRpYWxpemVkKCkgY29uc3QKQEAgLTE1MiwxOSArMTUyLDIwIEBAIGJvb2wgSW1hZ2VTb3VyY2U6
OmZyYW1lSXNDb21wbGV0ZUF0SW5kZXgKICAgICByZXR1cm4gKG1fZGVjb2RlciAmJiBtX2RlY29k
ZXItPmltYWdlQXRJbmRleChpbmRleCkgIT0gMCk7CiB9CiAKLXZvaWQgSW1hZ2VTb3VyY2U6OmNs
ZWFyKGJvb2wgZGVzdHJveUFsbCwgc2l6ZV90IGNsZWFyQmVmb3JlRnJhbWUpCit2b2lkIEltYWdl
U291cmNlOjpjbGVhcihib29sIGRlc3Ryb3lBbGwsIHNpemVfdCBjbGVhckJlZm9yZUZyYW1lLCBT
aGFyZWRCdWZmZXIqIGRhdGEsIGJvb2wgYWxsRGF0YVJlY2VpdmVkKQogewotICAgIGlmIChkZXN0
cm95QWxsKSB7Ci0gICAgICAgIGRlbGV0ZSAgbV9kZWNvZGVyOwotICAgICAgICBtX2RlY29kZXIg
PSAwOworICAgIGlmICghZGVzdHJveUFsbCkgeworICAgICAgICBpZiAobV9kZWNvZGVyKQorICAg
ICAgICAgICAgbV9kZWNvZGVyLT5jbGVhckZyYW1lQnVmZmVyQ2FjaGUoY2xlYXJCZWZvcmVGcmFt
ZSk7CiAgICAgICAgIHJldHVybjsKICAgICB9CiAKLSAgICBpZiAobV9kZWNvZGVyKQotICAgICAg
ICBtX2RlY29kZXItPmNsZWFyRnJhbWVCdWZmZXJDYWNoZShjbGVhckJlZm9yZUZyYW1lKTsKKyAg
ICBkZWxldGUgbV9kZWNvZGVyOworICAgIG1fZGVjb2RlciA9IDA7CisgICAgaWYgKGRhdGEpCisg
ICAgICBzZXREYXRhKGRhdGEsIGFsbERhdGFSZWNlaXZlZCk7CiB9CiAKLQogfQogCiAvLyB2aW06
IHRzPTQgc3c9NCBldApJbmRleDogV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy93eC9JbWFnZVNv
dXJjZVd4LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL3d4L0lt
YWdlU291cmNlV3guY3BwCShyZXZpc2lvbiAzOTQwNykKKysrIFdlYkNvcmUvcGxhdGZvcm0vZ3Jh
cGhpY3Mvd3gvSW1hZ2VTb3VyY2VXeC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTkzLDcgKzkzLDcg
QEAgSW1hZ2VTb3VyY2U6OkltYWdlU291cmNlKCkKIAogSW1hZ2VTb3VyY2U6On5JbWFnZVNvdXJj
ZSgpCiB7Ci0gICAgZGVsZXRlIG1fZGVjb2RlcjsKKyAgICBjbGVhcih0cnVlKTsKIH0KIAogYm9v
bCBJbWFnZVNvdXJjZTo6aW5pdGlhbGl6ZWQoKSBjb25zdApAQCAtMTU5LDEwICsxNTksMTggQEAg
Ym9vbCBJbWFnZVNvdXJjZTo6ZnJhbWVJc0NvbXBsZXRlQXRJbmRleAogICAgIHJldHVybiAobV9k
ZWNvZGVyICYmIG1fZGVjb2Rlci0+ZnJhbWVCdWZmZXJBdEluZGV4KGluZGV4KSAhPSAwKTsKIH0K
IAotdm9pZCBJbWFnZVNvdXJjZTo6Y2xlYXIoKQordm9pZCBJbWFnZVNvdXJjZTo6Y2xlYXIoYm9v
bCBkZXN0cm95QWxsLCBzaXplX3QgY2xlYXJCZWZvcmVGcmFtZSwgU2hhcmVkQnVmZmVyKiBkYXRh
LCBib29sIGFsbERhdGFSZWNlaXZlZCkKIHsKLSAgICBkZWxldGUgIG1fZGVjb2RlcjsKKyAgICBp
ZiAoIWRlc3Ryb3lBbGwpIHsKKyAgICAgICAgaWYgKG1fZGVjb2RlcikKKyAgICAgICAgICAgIG1f
ZGVjb2Rlci0+Y2xlYXJGcmFtZUJ1ZmZlckNhY2hlKGNsZWFyQmVmb3JlRnJhbWUpOworICAgICAg
ICByZXR1cm47CisgICAgfQorCisgICAgZGVsZXRlIG1fZGVjb2RlcjsKICAgICBtX2RlY29kZXIg
PSAwOworICAgIGlmIChkYXRhKQorICAgICAgc2V0RGF0YShkYXRhLCBhbGxEYXRhUmVjZWl2ZWQp
OwogfQogCiBOYXRpdmVJbWFnZVB0ciBJbWFnZVNvdXJjZTo6Y3JlYXRlRnJhbWVBdEluZGV4KHNp
emVfdCBpbmRleCkK
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>26216</attachid>
            <date>2008-12-22 15:45:59 -0800</date>
            <delta_ts>2008-12-26 19:50:09 -0800</delta_ts>
            <desc>patch v2</desc>
            <filename>patch</filename>
            <type>text/plain</type>
            <size>7250</size>
            <attacher name="Peter Kasting">pkasting</attacher>
            
              <data encoding="base64">SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n
CShyZXZpc2lvbiAzOTQ0MCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMzMgQEAKKzIwMDgtMTItMjIgIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n
bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg
IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjkyOQorCisgICAgICAg
IERvbid0IGNhbGwgc2V0RGF0YSgpIHJlcGVhdGVkbHkgd2hlbiBpdCdzIG5vdCBuZWNlc3Nhcnku
ICBQdXNoZXMgdGhlCisgICAgICAgIHJlc3BvbnNpYmlsaXR5IGZvciBjYWxsaW5nIHNldERhdGEo
KSBhZnRlciBjbGVhcigpIGludG8gdGhlCisgICAgICAgIEltYWdlU291cmNlIHdoaWNoIHByZXN1
bWFibHkga25vd3MgYmV0dGVyIHRoYW4gQml0bWFwSW1hZ2Ugd2hhdCBuZWVkcworICAgICAgICB0
byBiZSBkb25lLgorCisgICAgICAgIFdlIHVzZSB0aGlzIHRvIGZpeCBhIG1lbW9yeSByZWdyZXNz
aW9uIHdpdGggdGhlIENHIGRlY29kZXIgYnkKKyAgICAgICAgcmV2ZXJ0aW5nIHRvIHRoZSBvbGQg
ImRlc3Ryb3kgdGhlIGRlY29kZXIgYWZ0ZXIgZXZlcnkgZnJhbWUiIGJlaGF2aW9yLAorICAgICAg
ICB3aGlsZSBub3QgdG91Y2hpbmcgdGhlIG90aGVyIHBsYXRmb3JtcyB3aGVyZSBfbm90XyBkb2lu
ZyB0aGlzIHNhdmVzCisgICAgICAgIENQVS4KKworICAgICAgICAqIHBsYXRmb3JtL2dyYXBoaWNz
L0JpdG1hcEltYWdlLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkJpdG1hcEltYWdlOjpkZXN0cm95
RGVjb2RlZERhdGEpOgorICAgICAgICAqIHBsYXRmb3JtL2dyYXBoaWNzL0ltYWdlU291cmNlLmg6
CisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2Fpcm8vSW1hZ2VTb3VyY2VDYWlyby5jcHA6
CisgICAgICAgIChXZWJDb3JlOjpJbWFnZVNvdXJjZTo6Y2xlYXIpOgorICAgICAgICAqIHBsYXRm
b3JtL2dyYXBoaWNzL2NnL0ltYWdlU291cmNlQ0cuY3BwOgorICAgICAgICAoV2ViQ29yZTo6SW1h
Z2VTb3VyY2U6OmNsZWFyKToKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9xdC9JbWFnZVNv
dXJjZVF0LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkltYWdlU291cmNlOjp+SW1hZ2VTb3VyY2Up
OgorICAgICAgICAoV2ViQ29yZTo6SW1hZ2VTb3VyY2U6OmNsZWFyKToKKyAgICAgICAgKiBwbGF0
Zm9ybS9ncmFwaGljcy93eC9JbWFnZVNvdXJjZVd4LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6Oklt
YWdlU291cmNlOjp+SW1hZ2VTb3VyY2UpOgorICAgICAgICAoV2ViQ29yZTo6SW1hZ2VTb3VyY2U6
OmNsZWFyKToKKwogMjAwOC0xMi0yMiAgRGhhbmFuam95IENodXRpYSAgPGRoYW5yZEBnbWFpbC5j
b20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgRGF2aWQgS2lsemVyLgpJbmRleDogV2ViQ29yZS9w
bGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9w
bGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHAJKHJldmlzaW9uIDM5NDQwKQorKysgV2Vi
Q29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHAJKHdvcmtpbmcgY29weSkKQEAg
LTgwLDkgKzgwLDcgQEAgdm9pZCBCaXRtYXBJbWFnZTo6ZGVzdHJveURlY29kZWREYXRhKGJvbwog
CiAgICAgZGVzdHJveU1ldGFkYXRhQW5kTm90aWZ5KGZyYW1lc0NsZWFyZWQpOwogCi0gICAgbV9z
b3VyY2UuY2xlYXIoZGVzdHJveUFsbCwgY2xlYXJCZWZvcmVGcmFtZSk7Ci0gICAgaWYgKG1fZGF0
YSkKLSAgICAgICAgbV9zb3VyY2Uuc2V0RGF0YShtX2RhdGEuZ2V0KCksIG1fYWxsRGF0YVJlY2Vp
dmVkKTsKKyAgICBtX3NvdXJjZS5jbGVhcihkZXN0cm95QWxsLCBjbGVhckJlZm9yZUZyYW1lLCBt
X2RhdGEuZ2V0KCksIG1fYWxsRGF0YVJlY2VpdmVkKTsKICAgICByZXR1cm47CiB9CiAKSW5kZXg6
IFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvSW1hZ2VTb3VyY2UuaAo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBX
ZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0ltYWdlU291cmNlLmgJKHJldmlzaW9uIDM5NDQwKQor
KysgV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9JbWFnZVNvdXJjZS5oCSh3b3JraW5nIGNvcHkp
CkBAIC05OSw3ICs5OSwxNSBAQCBwdWJsaWM6CiAgICAgLy8gQ2FsbGVycyBzaG91bGQgbm90IGNh
bGwgY2xlYXIoZmFsc2UsIG4pIGFuZCBzdWJzZXF1ZW50bHkgY2FsbAogICAgIC8vIGNyZWF0ZUZy
YW1lQXRJbmRleChtKSB3aXRoIG0gPCBuLCB1bmxlc3MgdGhleSBmaXJzdCBjYWxsIGNsZWFyKHRy
dWUpLgogICAgIC8vIFRoaXMgZW5zdXJlcyB0aGF0IHN0YXRlZnVsIEltYWdlU291cmNlcy9kZWNv
ZGVycyB3aWxsIHdvcmsgcHJvcGVybHkuCi0gICAgdm9pZCBjbGVhcihib29sIGRlc3Ryb3lBbGws
IHNpemVfdCBjbGVhckJlZm9yZUZyYW1lID0gMCk7CisgICAgLy8KKyAgICAvLyBUaGUgfGRhdGF8
IGFuZCB8YWxsRGF0YVJlY2VpdmVkfCBwYXJhbWV0ZXJzIHNob3VsZCBiZSBzdXBwbGllZCBieSBj
YWxsZXJzCisgICAgLy8gd2hvIHNldCB8ZGVzdHJveUFsbHwgdG8gdHJ1ZSBpZiB0aGV5IHdpc2gg
dG8gYmUgYWJsZSB0byBjb250aW51ZSB1c2luZworICAgIC8vIHRoZSBJbWFnZVNvdXJjZS4gIFRo
aXMgd2F5IGltcGxlbWVudGF0aW9ucyB3aGljaCBjaG9vc2UgdG8gZGVzdHJveSB0aGVpcgorICAg
IC8vIGRlY29kZXJzIGluIHNvbWUgY2FzZXMgY2FuIHJlY29uc3RydWN0IHRoZW0gY29ycmVjdGx5
LgorICAgIHZvaWQgY2xlYXIoYm9vbCBkZXN0cm95QWxsLAorICAgICAgICAgICAgICAgc2l6ZV90
IGNsZWFyQmVmb3JlRnJhbWUgPSAwLAorICAgICAgICAgICAgICAgU2hhcmVkQnVmZmVyKiBkYXRh
ID0gTlVMTCwKKyAgICAgICAgICAgICAgIGJvb2wgYWxsRGF0YVJlY2VpdmVkID0gZmFsc2UpOwog
CiAgICAgYm9vbCBpbml0aWFsaXplZCgpIGNvbnN0OwogCkluZGV4OiBXZWJDb3JlL3BsYXRmb3Jt
L2dyYXBoaWNzL2NhaXJvL0ltYWdlU291cmNlQ2Fpcm8uY3BwCj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNv
cmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2Fpcm8vSW1hZ2VTb3VyY2VDYWlyby5jcHAJKHJldmlzaW9u
IDM5NDQwKQorKysgV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jYWlyby9JbWFnZVNvdXJjZUNh
aXJvLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTAwLDE2ICsxMDAsMTggQEAgSW1hZ2VTb3VyY2U6
On5JbWFnZVNvdXJjZSgpCiAgICAgY2xlYXIodHJ1ZSk7CiB9CiAKLXZvaWQgSW1hZ2VTb3VyY2U6
OmNsZWFyKGJvb2wgZGVzdHJveUFsbCwgc2l6ZV90IGNsZWFyQmVmb3JlRnJhbWUpCit2b2lkIElt
YWdlU291cmNlOjpjbGVhcihib29sIGRlc3Ryb3lBbGwsIHNpemVfdCBjbGVhckJlZm9yZUZyYW1l
LCBTaGFyZWRCdWZmZXIqIGRhdGEsIGJvb2wgYWxsRGF0YVJlY2VpdmVkKQogewotICAgIGlmIChk
ZXN0cm95QWxsKSB7Ci0gICAgICAgIGRlbGV0ZSBtX2RlY29kZXI7Ci0gICAgICAgIG1fZGVjb2Rl
ciA9IDA7CisgICAgaWYgKCFkZXN0cm95QWxsKSB7CisgICAgICAgIGlmIChtX2RlY29kZXIpCisg
ICAgICAgICAgICBtX2RlY29kZXItPmNsZWFyRnJhbWVCdWZmZXJDYWNoZShjbGVhckJlZm9yZUZy
YW1lKTsKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAotICAgIGlmIChtX2RlY29kZXIpCi0gICAg
ICAgIG1fZGVjb2Rlci0+Y2xlYXJGcmFtZUJ1ZmZlckNhY2hlKGNsZWFyQmVmb3JlRnJhbWUpOwor
ICAgIGRlbGV0ZSBtX2RlY29kZXI7CisgICAgbV9kZWNvZGVyID0gMDsKKyAgICBpZiAoZGF0YSkK
KyAgICAgIHNldERhdGEoZGF0YSwgYWxsRGF0YVJlY2VpdmVkKTsKIH0KIAogYm9vbCBJbWFnZVNv
dXJjZTo6aW5pdGlhbGl6ZWQoKSBjb25zdApJbmRleDogV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGlj
cy9jZy9JbWFnZVNvdXJjZUNHLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dy
YXBoaWNzL2NnL0ltYWdlU291cmNlQ0cuY3BwCShyZXZpc2lvbiAzOTQ0MCkKKysrIFdlYkNvcmUv
cGxhdGZvcm0vZ3JhcGhpY3MvY2cvSW1hZ2VTb3VyY2VDRy5jcHAJKHdvcmtpbmcgY29weSkKQEAg
LTQ4LDIzICs0OCwyOSBAQCBJbWFnZVNvdXJjZTo6fkltYWdlU291cmNlKCkKICAgICBjbGVhcih0
cnVlKTsKIH0KIAotdm9pZCBJbWFnZVNvdXJjZTo6Y2xlYXIoYm9vbCBkZXN0cm95QWxsLCBzaXpl
X3QgY2xlYXJCZWZvcmVGcmFtZSkKK3ZvaWQgSW1hZ2VTb3VyY2U6OmNsZWFyKGJvb2wgZGVzdHJv
eUFsbCwgc2l6ZV90IGNsZWFyQmVmb3JlRnJhbWUsIFNoYXJlZEJ1ZmZlciogZGF0YSwgYm9vbCBh
bGxEYXRhUmVjZWl2ZWQpCiB7Ci0gICAgaWYgKGRlc3Ryb3lBbGwpIHsKLSAgICAgICAgaWYgKG1f
ZGVjb2RlcikgewotICAgICAgICAgICAgQ0ZSZWxlYXNlKG1fZGVjb2Rlcik7Ci0gICAgICAgICAg
ICBtX2RlY29kZXIgPSAwOwotICAgICAgICB9CisgICAgLy8gVE9ETyhwa2FzdGluZyk6IGh0dHBz
Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjkyOQorICAgIC8vIElmIHdlIGRv
bid0IGRlc3Ryb3kgdGhlIGRlY29kZXIgaGVyZSAoYW5kIGRvbid0IHRlbGwgdGhlIENHIGRlY29k
ZXIgdG8KKyAgICAvLyBkaXNjYXJkIGZyYW1lcyBhcyBwcm9wb3NlZCBpbiB0aGUgYmVsb3cgY29t
bWVudCksIGl0IHVzZXMgdG9vIG11Y2gKKyAgICAvLyBtZW1vcnkuCisjaWYgMAorICAgIGlmICgh
ZGVzdHJveUFsbCkgeworICAgICAgICAvLyBUT0RPKHBrYXN0aW5nKTogSWYgdGhlcmUgd2FzIGFu
IGFwcHJvcHJpYXRlIEFQSSB0byBkbyBzbywgd2UgY291bGQKKyAgICAgICAgLy8gZXhwbGljaXRs
eSB0ZWxsIHRoZSBDRyBkZWNvZGVyIGl0IGNhbiBkaXNjYXJkIGZyYW1lcyBiZWZvcmUKKyAgICAg
ICAgLy8gfGNsZWFyQmVmb3JlRnJhbWV8IChub3QgaW5jbHVkaW5nIGFueXRoaW5nIGl0IG5lZWRz
IHRvIGtlZXAgYXJvdW5kCisgICAgICAgIC8vIGxvY2FsbHkgdG8gY29udGludWUgZGVjb2Rpbmcg
Y29ycmVjdGx5KS4gIFRoaXMgbWlnaHQgaGVscCB0aGUgZGVjb2RlcgorICAgICAgICAvLyBvcHRp
bWl6ZSBtZW1vcnkvQ1BVIHVzYWdlLgogICAgICAgICByZXR1cm47CiAgICAgfQorI2VuZGlmCiAK
LSAgICAvLyBUT0RPKHBrYXN0aW5nKTogSWYgdGhlcmUgd2FzIGFuIGFwcHJvcHJpYXRlIEFQSSB0
byBkbyBzbywgd2UgY291bGQKLSAgICAvLyBleHBsaWNpdGx5IHRlbGwgdGhlIENHIGRlY29kZXIg
aXQgY2FuIGRpc2NhcmQgZnJhbWVzIGJlZm9yZQotICAgIC8vIHxjbGVhckJlZm9yZUZyYW1lfCAo
bm90IGluY2x1ZGluZyBhbnl0aGluZyBpdCBuZWVkcyB0byBrZWVwIGFyb3VuZAotICAgIC8vIGxv
Y2FsbHkgdG8gY29udGludWUgZGVjb2RpbmcgY29ycmVjdGx5KS4gIFRoaXMgbWlnaHQgaGVscCB0
aGUgZGVjb2RlcgotICAgIC8vIG9wdGltaXplIG1lbW9yeS9DUFUgdXNhZ2UuICBSaWdodCBub3cg
dGhlIGRlY29kZXIgc2VlbXMgdG8gdGhyb3cgYXdheQotICAgIC8vIGZyYW1lcyBhZ2dyZXNzaXZl
bHkgYW5kIHRoZW4gcmUtZGVjb2RlIGZyb20gdGhlIGJlZ2lubmluZyBlYWNoIHRpbWUsIHRodXMK
LSAgICAvLyB1c2luZyBtb3JlIENQVSB0aGFuIGl0IG5lZWRzIHRvLgorICAgIGlmIChtX2RlY29k
ZXIpIHsKKyAgICAgICAgQ0ZSZWxlYXNlKG1fZGVjb2Rlcik7CisgICAgICAgIG1fZGVjb2RlciA9
IDA7CisgICAgfQorICAgIGlmIChkYXRhKQorICAgICAgc2V0RGF0YShkYXRhLCBhbGxEYXRhUmVj
ZWl2ZWQpOwogfQogCiBDRkRpY3Rpb25hcnlSZWYgaW1hZ2VTb3VyY2VPcHRpb25zKCkKSW5kZXg6
IFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvcXQvSW1hZ2VTb3VyY2VRdC5jcHAKPT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9xdC9JbWFnZVNvdXJjZVF0LmNwcAkocmV2
aXNpb24gMzk0NDApCisrKyBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL3F0L0ltYWdlU291cmNl
UXQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC00NSw3ICs0NSw3IEBAIEltYWdlU291cmNlOjpJbWFn
ZVNvdXJjZSgpCiAKIEltYWdlU291cmNlOjp+SW1hZ2VTb3VyY2UoKQogewotICAgIGRlbGV0ZSBt
X2RlY29kZXI7CisgICAgY2xlYXIodHJ1ZSk7CiB9CiAKIGJvb2wgSW1hZ2VTb3VyY2U6OmluaXRp
YWxpemVkKCkgY29uc3QKQEAgLTE1MiwxOSArMTUyLDIwIEBAIGJvb2wgSW1hZ2VTb3VyY2U6OmZy
YW1lSXNDb21wbGV0ZUF0SW5kZXgKICAgICByZXR1cm4gKG1fZGVjb2RlciAmJiBtX2RlY29kZXIt
PmltYWdlQXRJbmRleChpbmRleCkgIT0gMCk7CiB9CiAKLXZvaWQgSW1hZ2VTb3VyY2U6OmNsZWFy
KGJvb2wgZGVzdHJveUFsbCwgc2l6ZV90IGNsZWFyQmVmb3JlRnJhbWUpCit2b2lkIEltYWdlU291
cmNlOjpjbGVhcihib29sIGRlc3Ryb3lBbGwsIHNpemVfdCBjbGVhckJlZm9yZUZyYW1lLCBTaGFy
ZWRCdWZmZXIqIGRhdGEsIGJvb2wgYWxsRGF0YVJlY2VpdmVkKQogewotICAgIGlmIChkZXN0cm95
QWxsKSB7Ci0gICAgICAgIGRlbGV0ZSAgbV9kZWNvZGVyOwotICAgICAgICBtX2RlY29kZXIgPSAw
OworICAgIGlmICghZGVzdHJveUFsbCkgeworICAgICAgICBpZiAobV9kZWNvZGVyKQorICAgICAg
ICAgICAgbV9kZWNvZGVyLT5jbGVhckZyYW1lQnVmZmVyQ2FjaGUoY2xlYXJCZWZvcmVGcmFtZSk7
CiAgICAgICAgIHJldHVybjsKICAgICB9CiAKLSAgICBpZiAobV9kZWNvZGVyKQotICAgICAgICBt
X2RlY29kZXItPmNsZWFyRnJhbWVCdWZmZXJDYWNoZShjbGVhckJlZm9yZUZyYW1lKTsKKyAgICBk
ZWxldGUgbV9kZWNvZGVyOworICAgIG1fZGVjb2RlciA9IDA7CisgICAgaWYgKGRhdGEpCisgICAg
ICBzZXREYXRhKGRhdGEsIGFsbERhdGFSZWNlaXZlZCk7CiB9CiAKLQogfQogCiAvLyB2aW06IHRz
PTQgc3c9NCBldAo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>26542</attachid>
            <date>2009-01-08 16:01:07 -0800</date>
            <delta_ts>2009-01-08 16:51:47 -0800</delta_ts>
            <desc>memory regression patch v1</desc>
            <filename>patch</filename>
            <type>text/plain</type>
            <size>1676</size>
            <attacher name="Peter Kasting">pkasting</attacher>
            
              <data encoding="base64">SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n
CShyZXZpc2lvbiAzOTcyNSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMTMgQEAKKzIwMDktMDEtMDggIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n
bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg
IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMjkyOQorICAgICAgICBG
aXggbWVtb3J5IHJlZ3Jlc3Npb24gd2hlbiBkZWNvZGluZyBsYXJnZSBhbmltYXRlZCBHSUZzLgor
CisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2cvSW1hZ2VTb3VyY2VDRy5jcHA6CisgICAg
ICAgIChXZWJDb3JlOjpJbWFnZVNvdXJjZTo6Y2xlYXIpOgorCiAyMDA5LTAxLTA4ICBBbnR0aSBL
b2l2aXN0byAgPGFudHRpQGFwcGxlLmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBPbGl2ZXIg
SHVudC4KSW5kZXg6IFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2cvSW1hZ2VTb3VyY2VDRy5j
cHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jZy9JbWFnZVNvdXJj
ZUNHLmNwcAkocmV2aXNpb24gMzk2OTQpCisrKyBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2Nn
L0ltYWdlU291cmNlQ0cuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC01MCwxNSArNTAsOSBAQCBJbWFn
ZVNvdXJjZTo6fkltYWdlU291cmNlKCkKIAogdm9pZCBJbWFnZVNvdXJjZTo6Y2xlYXIoYm9vbCBk
ZXN0cm95QWxsLCBzaXplX3QsIFNoYXJlZEJ1ZmZlciogZGF0YSwgYm9vbCBhbGxEYXRhUmVjZWl2
ZWQpCiB7Ci0gICAgaWYgKCFkZXN0cm95QWxsKSB7Ci0gICAgICAgIC8vIFRPRE8ocGthc3Rpbmcp
OiBJZiB0aGVyZSB3YXMgYW4gYXBwcm9wcmlhdGUgQVBJIHRvIGRvIHNvLCB3ZSBjb3VsZAotICAg
ICAgICAvLyBleHBsaWNpdGx5IHRlbGwgdGhlIENHIGRlY29kZXIgaXQgY2FuIGRpc2NhcmQgZnJh
bWVzIGJlZm9yZQotICAgICAgICAvLyB8Y2xlYXJCZWZvcmVGcmFtZXwgKG5vdCBpbmNsdWRpbmcg
YW55dGhpbmcgaXQgbmVlZHMgdG8ga2VlcCBhcm91bmQKLSAgICAgICAgLy8gbG9jYWxseSB0byBj
b250aW51ZSBkZWNvZGluZyBjb3JyZWN0bHkpLiAgVGhpcyBtaWdodCBoZWxwIHRoZSBkZWNvZGVy
Ci0gICAgICAgIC8vIG9wdGltaXplIG1lbW9yeS9DUFUgdXNhZ2UuCi0gICAgICAgIHJldHVybjsK
LSAgICB9Ci0KKyAgICAvLyBXZSBhbHdheXMgZGVzdHJveSB0aGUgZGVjb2RlciwgYmVjYXVzZSB0
aGVyZSBpcyBubyBBUEkgdG8gZ2V0IGl0IHRvCisgICAgLy8gc2VsZWN0aXZlbHkgcmVsZWFzZSBz
b21lIG9mIHRoZSBmcmFtZXMgaXQncyBob2xkaW5nLCBhbmQgaWYgd2UgZG9uJ3QKKyAgICAvLyBy
ZWxlYXNlIGFueSBvZiB0aGVtLCB3ZSB1c2UgdG9vIG11Y2ggbWVtb3J5IG9uIGxhcmdlIGltYWdl
cy4KICAgICBpZiAobV9kZWNvZGVyKSB7CiAgICAgICAgIENGUmVsZWFzZShtX2RlY29kZXIpOwog
ICAgICAgICBtX2RlY29kZXIgPSAwOwo=
</data>
<flag name="review"
          id="12612"
          type_id="1"
          status="+"
          setter="sam"
    />
          </attachment>
      

    </bug>

</bugzilla>