30827 2009-10-27 10:31:12 -0700 Off-by-one hard-to-trigger memory corruption in CSSParser (seen only with GCC 4.4) 2009-11-03 10:37:54 -0800 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC All RESOLVED FIXED P2 Normal --- 1 evan evan ap commit-queue craig.schlenter darin hyatt scarybeasts tcallawa oldest_to_newest 158246 0 evan 2009-10-27 10:31:12 -0700 See http://code.google.com/p/chromium/issues/detail?id=23362 for the gory details. Here's a summary of multiple people's hard work. Build WebKit with GCC 4.4 and use either: - glibc's MALLOC_CHECK support - valgrind and find that some pages cause, respectively, either a crash or an invalid read/write. Example URLs: http://artofapogee.blogspot.com/2009/05/ubuntu-my-2009-t-shirt-design.html http://msnbc.com http://www.cs.colorado.edu/~jessup/lapack/ The crash is due to a double free in WebCore::~CSSParser, but that could be due to memory corruption. A partial backtrace at the invalid write found by valgrind follows: #0 0x0000000001a811a0 in WebCore::CSSParser::lex (this=0x7feffd780) at ../css/tokenizer.flex:47 #1 0x0000000001a7ef4e in WebCore::CSSParser::lex (this=0x7feffd780, yylvalWithoutType=0x7feffd1e0) at third_party/WebKit/WebCore/css/CSSParser.cpp:4607 #2 0x0000000001c7e8aa in cssyylex (cssyylval=0x7feffd1e0, parser=0x7feffd780) at /home/shenki/src/chromium/src/third_party/WebKit/WebCore/css/CSSGrammar.y:95 #3 0x0000000001c7eb2e in cssyyparse (parser=0x7feffd780) at out/Debug/obj.target/geni/CSSGrammar.cpp:2060 #4 0x0000000001a6ebc5 in WebCore::CSSParser::parseSheet (this=0x7feffd780, sheet=0x101b32c0, string=...) at third_party/WebKit/WebCore/css/CSSParser.cpp:225 #5 0x0000000001ad617d in WebCore::CSSStyleSheet::parseString (this=0x101b32c0, string=..., strict=false) at third_party/WebKit/WebCore/css/CSSStyleSheet.cpp:167 #6 0x00000000014972ec in WebCore::HTMLLinkElement::setCSSStyleSheet (this=0x1013e050, url=..., charset=..., sheet=0x1013eef0) at third_party/WebKit/WebCore/html/HTMLLinkElement.cpp:269 #7 0x00000000014f22d7 in WebCore::CachedCSSStyleSheet::checkNotify (this=0x1013eef0) at third_party/WebKit/WebCore/loader/CachedCSSStyleSheet.cpp:115 #8 0x00000000014f21c3 in WebCore::CachedCSSStyleSheet::data (this=0x1013eef0, data=..., allDataReceived=true) at third_party/WebKit/WebCore/loader/CachedCSSStyleSheet.cpp:103 The CSS for the lapack URL does not cause a crash if the size of the file is adjusted by any number of bytes(!!), smaller or larger. It also does not cause a crash if the error in the css is fixed (line 98, add a closing brace). If you add 1 to the data malloc'd in WebCore/css/CSSParser.cpp line 199, it works around the issue. 158268 1 41966 evan 2009-10-27 10:51:10 -0700 Created attachment 41966 lapack css This is the style.css that is involved in one instance of the crash, with the missing semicolon on line 98 mentioned in the bug. 158273 2 darin 2009-10-27 11:06:36 -0700 The fact that allocating one more byte make the bug goes away makes me think this is a buffer overrun of some sort. The flex documentation mentions that you need to supply a buffer where the last two bytes are 0 when explaining how to use the yy_scan_buffer, which I think is analogous to how we use flex. So it makes sense that CSSParser sets the last two characters to 0, and that should guarantee we never run off the end of the buffer. What I can't tell is exactly how flex guarantees it won't read or write more than two characters past the end of the buffer. That guarantee somehow comes from the state table that flex generates. Trying to guess how the incorrect CSS in the lapack example affects this I think it's possible the problem might stem from calling flex again after flex returns an end of file indication. 158281 3 evan 2009-10-27 11:30:48 -0700 One additional fact I left out: it appears that the discriminating difference to trigger this is GCC 4.4 rather than GCC 4.3. It doesn't happen to Google-based Chrome developers who are using GCC 4.3 (and likely also OS X WebKit devs). It does happen to people building on both Fedora and Ubuntu with GCC 4.4. 158287 4 darin 2009-10-27 11:39:03 -0700 (In reply to comment #3) > One additional fact I left out: it appears that the discriminating difference > to trigger this is GCC 4.4 rather than GCC 4.3. It doesn't happen to > Google-based Chrome developers who are using GCC 4.3 (and likely also OS X > WebKit devs). It does happen to people building on both Fedora and Ubuntu with > GCC 4.4. That points to either a compiler bug or a side effect of more aggressive optimization, then. 158295 5 craig.schlenter 2009-10-27 11:51:31 -0700 A couple of quick comments: The valgrind trace shows 2 bytes being overwritten not just 1. Valgrind also shows a 2 byte read error. So while adding 1 byte might fix it, I think 2 might be better if we just wanted to paper over the error. It would be nice to understand why the parsing is overrunning though ... my reading of the valgrind trace and the code suggests that it should be here: (from tokenizer.cpp which is autogenerated) #line 47 "../css/tokenizer.flex" {yyTok = STRING; return yyTok;} YY_BREAK case 15: /* rule 15 can match eol */ YY_RULE_SETUP but I'm not seeing anything writing to memory there which is confusing... 158298 6 darin 2009-10-27 11:54:57 -0700 To get a better understanding of what is going on you should look at the generated code, tokenizer.cpp, not the source code, tokenizer.flex. And tokenizer.cpp is included in CSSParser.cpp, which has other code you'll need to see to understand it. As I said, the guarantee it won't run off the end of the buffer comes from the flex-generated state tables, and is not obvious from just reading the code. 158321 7 scarybeasts 2009-10-27 12:43:32 -0700 It may not be a GCC4.4 optimization issue, but an issue with the lex code itself. e.g. here's a crash report on Windows in ::lex() http://crash/reportdetail?reportid=3b8c4b9de1f9b57a It crashes hitting a page boundary - which is one possible symptom of an off-by-one. It's not a strong signal, though. 158333 8 evan 2009-10-27 13:18:45 -0700 Paste of the backtrace from that Chrome bug for the benefit of the WebKit guys: 0x01dcdb73 [chrome.dll - tokenizer.flex:21] WebCore::CSSParser::lex() 0x01dccbe5 [chrome.dll - cssparser.cpp:4331] WebCore::CSSParser::lex(void *) 0x01e74aa3 [chrome.dll - cssgrammar.cpp:2119] cssyyparse(void *) 0x01d86eca [chrome.dll - cssstylesheet.cpp:164] WebCore::CSSStyleSheet::parseString(WebCore::String const &,bool) 0x01cbfd02 [chrome.dll - htmllinkelement.cpp:255] WebCore::HTMLLinkElement::setCSSStyleSheet(WebCore::String const &,WebCore::String const &,WebCore::CachedCSSStyleSheet const *) 158334 9 darin 2009-10-27 13:24:36 -0700 An editorial comment: This lexer code dates back to very early in the project, and was done by Lars Knoll. There is not necessarily a “WebKit guy” who’s already expert on this. So don’t wait for an expert to show up! Make yourself into one. 158336 10 evan 2009-10-27 13:26:43 -0700 Yeah, I didn't mean to say I was pawning it off on you -- I just hate it when people paste bug tracker URLs to bug trackers that I can't see. :) 158337 11 darin 2009-10-27 13:32:18 -0700 (In reply to comment #4) > (In reply to comment #3) > > One additional fact I left out: it appears that the discriminating difference > > to trigger this is GCC 4.4 rather than GCC 4.3. > > That points to either a compiler bug or a side effect of more aggressive > optimization, then. (In reply to comment #7) > It may not be a GCC4.4 optimization issue, but an issue with the lex code > itself. Agreed. What I meant by “side effect of more aggressive optimization” was to raise the possibility GCC 4.4 might do a correct optimization that GCC 4.3 does not, and this means that incorrect code produced by lex has a symptom that was latent before. If it showed up with GCC 4.3 as well, I would not suspect that, but since it does not, I do suspect it. Has anyone reproduced this bug with an unoptimized debug build? 158576 12 craig.schlenter 2009-10-28 08:58:55 -0700 Joel's backtrace appears to have come from a debug build: From valgrind-lapack.txt from http://code.google.com/p/chromium/issues/detail?id=23362#c41 tools/valgrind/valgrind.sh out/Debug/chrome --user-data-dir=/tmp/chrome http://www.cs.colorado.edu/~jessup/lapack/ Darin: would you consider a patch that cranks up the buffer size to work around this temporarily until we can make more sense of this? I unfortunately can't reproduce this on my machine so debugging it is problematic :( 158583 13 darin 2009-10-28 09:17:46 -0700 (In reply to comment #12) > Darin: would you consider a patch that cranks up the buffer size to work around > this temporarily until we can make more sense of this? I’d like to hear your take on the pros and cons of taking that action. If our primary goal is to diagnose and fully fix the problem, it’s possible that applying a patch that makes its symptoms go away for reasons we don’t fully understand may make our task more difficult rather than easier. Perhaps you have another goal? 158586 14 evan 2009-10-28 09:22:37 -0700 Since this only affects people who build with GCC 4.4, at least in the Chrome world that means Linux distros, who already carry a variety of downstream patches. I guess this ought to affect the other Linux WebKits as well; I don't know whether they also apply out-of-tree patches before releasing. 158647 15 craig.schlenter 2009-10-28 11:27:38 -0700 (In reply to comment #13) > If our primary goal is to diagnose and fully fix the problem, it’s possible > that applying a patch that makes its symptoms go away for reasons we don’t > fully understand may make our task more difficult rather than easier. Perhaps > you have another goal? My goal was to stop possible crashes in the field without requiring package builders using gcc 4.4 to carry extra patches until the problem is properly resolved. Part of the rationale for suggesting this was that it looks like the problem might take a while to solve and I was anticipating that when debugging the problem it would be easy to revert the patch locally if desired. But if you feel that approach is undesirable, it's easy enough for the packagers to include a local patch for now... 158664 16 darin 2009-10-28 12:34:57 -0700 (In reply to comment #15) > My goal was to stop possible crashes in the field without requiring package > builders using gcc 4.4 to carry extra patches until the problem is properly > resolved. Seems OK to me, although a bit sloppy. > Part of the rationale for suggesting this was that it looks like the > problem might take a while to solve and I was anticipating that when debugging > the problem it would be easy to revert the patch locally if desired. I agree this won’t cause much difficulty debugging the problem. Typically we hold off on making a change that just makes a bug go away until we understand why it does. Maybe this is a special case. 159494 17 evan 2009-10-30 15:54:35 -0700 After some quality time with Valgrind, I have a fix; will post a patch and an explanation in a bit. Going to play around a bit to see if I can make a reduced test case. 159502 18 42241 evan 2009-10-30 16:09:45 -0700 Created attachment 42241 repro of the crasher The attached test reliably crashes on my 64-bit machine with GCC 4.4. If anyone's on a 32-bit machine that has reproduced the crasher, can you verify that this also crashes for you? If not, can you try adding more letters (one at a time) to the "tenbytes" seen in the style tag and tell me if there's any other number of bytes that better triggers the crash for you? 159514 19 evan 2009-10-30 16:31:34 -0700 Ok, so here's what's going on. Darin's guess seems right on. We run flex to generate a lexer, then the perl script "maketokenizer" to munge the flex output into something WebKit can use -- for example, the character buffer contains UChars, not chars. maketokenizer is pretty magical; part of my patch is to add a few more comments to it. One of the things it does is remove the flex end-of-buffer handling code, which is 20+ lines of code that normally tries to go on to the next "input file" (which doesn't make sense within WebKit). flex hits the end of buffer state when the input hits two consecutive NULs. The first point where Valgrind complained was that we were reading one character (two bytes -- that's why the valgrind complaints we were seeing involved 2 bytes instead of one, because characters are two bytes) past the end of the buffer. Some careful reading of the flex end of buffer code reveals that it backs up by one byte in the EOB case -- I imagine this is because we still want to point at the trailing two NULs if we attempt to resume lexing on the same buffer. I'll attach a patch that fixes my layout test, but I'm not perfectly confident about it. flex has a lot of magical pointer variables and they're all not clear. I'll paste the normal flex end of buffer code below -- the key observation to make is that yy_amount_of_matched_text gets computed with an extra -1, but then yy_c_buf_p gets updated to be yytext + yy_amount_of_matched_text without adding in the -1. I don't understand flex at all, but yy_cp is a variable that starts at yy_c_buf_p and moves forward during the loop, the latter is the one that persists. My patch does fix the crash, though I'm not certain it's correct or that it'll work on other systems. Needs more experimentation. case YY_END_OF_BUFFER: { /* Amount of text matched not including the EOB char. */ int yy_amount_of_matched_text = (int) (yy_cp - (yytext_ptr)) - 1; /* Undo the effects of YY_DO_BEFORE_ACTION. */ *yy_cp = (yy_hold_char); YY_RESTORE_YY_MORE_OFFSET if ( YY_CURRENT_BUFFER_LVALUE->yy_buffer_status == YY_BUFFER_NEW ) { /* We're scanning a new file or input source. It's * possible that this happened because the user * just pointed yyin at a new source and called * yylex(). If so, then we have to assure * consistency between YY_CURRENT_BUFFER and our * globals. Here is the right place to do so, because * this is the first action (other than possibly a * back-up) that will match for the new input source. */ (yy_n_chars) = YY_CURRENT_BUFFER_LVALUE->yy_n_chars; YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin; YY_CURRENT_BUFFER_LVALUE->yy_buffer_status = YY_BUFFER_NORMAL; } /* Note that here we test for yy_c_buf_p "<=" to the position * of the first EOB in the buffer, since yy_c_buf_p will * already have been incremented past the NUL character * (since all states make transitions on EOB to the * end-of-buffer state). Contrast this with the test * in input(). */ if ( (yy_c_buf_p) <= &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[(yy_n_chars)] ) { /* This was really a NUL. */ yy_state_type yy_next_state; (yy_c_buf_p) = (yytext_ptr) + yy_amount_of_matched_text; 159515 20 42244 evan 2009-10-30 16:33:04 -0700 Created attachment 42244 patch and layout test 159516 21 42244 darin 2009-10-30 16:40:16 -0700 Comment on attachment 42244 patch and layout test Next time, please set review? on a patch to indicate you'd like review. Unless you intentionally left that out here. > +<style>tenbytes {</style> > + > +This test tickles a subtle off-by-one bug in how WebKit's CSS lexer > +handles end of buffer conditions.<p> > + > +The contents of the style tag satisfy (length mod 8 = 2) and contain an > +unclosed curly brace. We pass if we don't crash.<p> > + > +PASS The use of <p> here is incorrect. It's a container, not a separator. <p> goes at the start of a paragraph and then </p> at the end of it. This test needs to have some code to make it dump text-only results so we have a platform-independent test. Like this: <script> if (window.layoutTestController) layoutTestController.dumpAsText(); </script> The patch needs to include expected results for the test, generated by running the run-webkit-tests script. Patch otherwise looks very good. Great fix! review- because the test needs results 159537 22 evan 2009-10-30 19:47:42 -0700 I didn't set review? because I knew I needed to do more work before it was good to go, like test baselines and such, and I was running out the door. Not quite sure what the proper protocol for "this isn't good enough yet, but what do you think?" is. I'll make a proper patch on Monday. If anyone reading this can try the test attached to this bug on a 32-bit system where they encountered the crash, I'd be interested to hear positive/negative results. 159594 23 darin 2009-10-31 15:55:46 -0700 (In reply to comment #22) > Not quite > sure what the proper protocol for "this isn't good enough yet, but what do you > think?" is. Comment in the bug or email. 159891 24 42334 evan 2009-11-02 12:23:59 -0800 Created attachment 42334 patch and layout test 159892 25 42334 evan 2009-11-02 12:25:22 -0800 Comment on attachment 42334 patch and layout test I'm not perfectly happy with this test (it only seems to repro on GCC 4.4 + 64-bit, not even 32-bit) but I have confirmed that I get a crash with the patch and no crash without. 159906 26 darin 2009-11-02 13:22:19 -0800 (In reply to comment #25) > I'm not perfectly happy with this test (it only seems to repro on GCC 4.4 + > 64-bit, not even 32-bit) but I have confirmed that I get a crash with the patch > and no crash without. One think that might make the test more valuable is to find a way to introduce bounds checking assertions that check the value of the buffer pointer at key points. With that, a debug build and this test case could demonstrate the buffer overrun even in cases where it's not causing a crash. 160120 27 42334 commit-queue 2009-11-03 10:37:47 -0800 Comment on attachment 42334 patch and layout test Clearing flags on attachment: 42334 Committed r50467: <http://trac.webkit.org/changeset/50467> 160121 28 commit-queue 2009-11-03 10:37:54 -0800 All reviewed patches have been landed. Closing bug. 41966 2009-10-27 10:51:10 -0700 2009-10-27 10:51:10 -0700 lapack css style.css text/css 2218 evan Qk9EWSB7ICAgICAgIA0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZmZmZjsNCiAgICAgIHRl eHQtZGVjb3JhdGlvbjogbm9uZTsNCn0gDQoNClAgeyAgIA0KICAgICAgbWFyZ2luLWxlZnQ6MTBw eDsNCiAgICAgIGZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOw0KICAg ICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGZvbnQtc2l6ZTogMTFwdDsNCiAgICAgIGNv bG9yOiAjMTkxOTcwOw0KfQ0KDQpURCB7ICAgICAgIA0KICAgICAgbWFyZ2luLXJpZ2h0OiAxMHB4 Ow0KfQ0KDQpVTCB7DQogICAgICBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsNCiAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICBmb250LXNpemU6IDExcHQ7 DQogICAgICBjb2xvcjogIzE5MTk3MDsNCn0NCg0KSDIgew0KICAgICAgY29sb3I6ICNjNzE1ODU7 DQogICAgICBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsNCiAgICAg IGZvbnQtc2l6ZTogMTMwJTsNCn0NCg0KSDMgew0KICAgICAgY29sb3I6ICNjNzE1ODU7DQogICAg ICBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsNCiAgICAgIGZvbnQt c2l6ZTogMTEwJQ0KfQ0KDQpCIHsNCiAgICAgIGNvbG9yOiAjYzcxNTg1Ow0KICAgICAgZm9udC13 ZWlnaHQ6IGJvbGQ7DQp9DQoNCi8qIFRoaXMgaXMgdGhlIGxlZnQtc2lkZSBtZW51ICovDQouYmln bWVudSB7ICAgICAgIA0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZmZjYzsgICAgICAgICAg ICANCiAgICAgIGZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAgDQog ICAgICBmb250LXdlaWdodDogYm9sZDsNCiAgICAgIGNvbG9yOiAjMzM5OTAwOw0KfQ0KDQovKiBU aGlzIGlzIHRoZSBzdWJtZW51IGZvciBBY2Nlc3MgUm91dGluZXMgKi8gDQoubWVudSB7ICAgICAg IA0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZmZjYzsgICAgICAgICAgICANCiAgICAgIGZv bnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAgDQogICAgICBmb250LXNp emU6IDEwcHQ7ICAgICANCiAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOw0KICAgICAgY29sb3I6ICMz Mzk5MDA7DQp9DQoNCi8qIFRoaXMgaXMgdGhlIHN1Ym1lbnUgZm9yIFF1aWNrIExpbmtzICovDQou YmlncXVpY2tsaW5rcyB7DQogCSBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmNjOyAgDQoJIGNvbG9y OiAjYzcxNTg1Ow0KICAgICBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgICAgICAgDQogICAgIGZvbnQtd2VpZ2h0OiBib2xkOw0KfQ0KDQovKiBUaGlzIGlzIHRoZSBz dWJtZW51IGZvciBRdWljayBMaW5rcyAqLw0KLnF1aWNrbGlua3Mgew0KICAgICBiYWNrZ3JvdW5k LWNvbG9yOiAjZmZmZmNjOyAgDQoJIGNvbG9yOiAjYzcxNTg1Ow0KICAgICBmb250LWZhbWlseTog QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIA0KICAgICBmb250LXNpemU6IDEwcHQ7ICAg ICANCiAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7DQp9DQoNCi8qIFRoaXMgaXMgdGhlIGJvdHRvbSBt ZW51IGZvciB0aGUgR2VuZXJhbCBJbmZvIHBhZ2VzICovDQouc3ViIHsNCiAgICAgIGZvbnQtc2l6 ZTogMTBwdDsNCiAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICBjb2xvcjogIzMzMDBm ZjsNCn0NCg0KLyogVGhpcyBpcyB0aGUgdG9wIGZyYW1lIG1lbnUgKi8NCi5hYm92ZSB7ICAgICAg IA0KICAgICAgZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7DQogICAg ICBmb250LXNpemU6IDEwcHQ7ICAgICAgIA0KICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7DQp9DQoN Ci8qIFRoaXMgaXMgZm9yIGxpbmtzIGluc2lkZSB0aGUgdGV4dCAqLw0KLmludGV4dCB7DQogICAg ICBjb2xvcjogIzMzMDBmZjsNCiAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7DQp9DQoNCi5zbWFs bCB7DQogICAgICBmb250LXdlaWdodDogbm9ybWFsOw0KDQpBOmxpbmsgeyAgICAgICANCiAgICAg IGNvbG9yOiAjMzMwMGZmOyAgICANCn0gIA0KDQpBOnZpc2l0ZWQgeyAgICAgICANCiAgICAgIGNv bG9yOiAjMzMwMGZmOyAgICANCn0gIA0KDQpBOmFjdGl2ZSB7ICAgICAgIA0KICAgICAgY29sb3I6 ICMzMzAwZmY7ICAgIA0KfSANCg0KQSB7DQogICAgICBjb2xvcjogIzMzOTkwMDsNCn0NCg== 42241 2009-10-30 16:09:45 -0700 2009-10-30 16:09:45 -0700 repro of the crasher test.html text/html 264 evan PHN0eWxlPnRlbmJ5dGVzIHs8L3N0eWxlPgoKVGhpcyB0ZXN0IHRpY2tsZXMgYSBzdWJ0bGUgb2Zm LWJ5LW9uZSBidWcgaW4gaG93IFdlYktpdCdzIENTUyBsZXhlcgpoYW5kbGVzIGVuZCBvZiBidWZm ZXIgY29uZGl0aW9ucy4gIFRoZSBjb250ZW50cyBvZiB0aGUgc3R5bGUgdGFnIG11c3QKc2F0aXNm eSAobGVuZ3RoIG1vZCA4ID0gMikgYW5kIGNvbnRhaW4gYW4gdW5jbG9zZWQgc2VtaWNvbG9uLiAg V2UKcGFzcyBpZiB3ZSBkb24ndCBjcmFzaC48cD4KClBBU1MK 42244 2009-10-30 16:33:04 -0700 2009-11-02 12:24:38 -0800 patch and layout test bug-30827-20091030163303.patch text/plain 3926 evan ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBhOTg4ZTQ0Li45ZWRhNjdlIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMDktMTAt MzAgIEV2YW4gTWFydGluICA8ZXZhbkBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQSB0ZXN0IHRoYXQgcmVwcm9kdWNlcyBhIGhh cmQtdG8tdHJpZ2dlciBtZW1vcnkgY29ycnVwdGlvbiBpbiB0aGUKKyAgICAgICAgQ1NTIGxleGVy LgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zMDgy NworCisgICAgICAgICogZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC5odG1sOiBBZGRlZC4K KwogMjAwOS0xMC0zMCAgU2hpbmljaGlybyBIYW1hamkgIDxoYW1hamlAY2hyb21pdW0ub3JnPgog CiAgICAgICAgIFJldmlld2VkIGJ5IE1hcmsgUm93ZS4KZGlmZiAtLWdpdCBhL0xheW91dFRlc3Rz L2Zhc3QvY3NzL2VuZC1vZi1idWZmZXItY3Jhc2guaHRtbCBiL0xheW91dFRlc3RzL2Zhc3QvY3Nz L2VuZC1vZi1idWZmZXItY3Jhc2guaHRtbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAw MDAwLi5iNDVhZGQ3Ci0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC9jc3MvZW5k LW9mLWJ1ZmZlci1jcmFzaC5odG1sCkBAIC0wLDAgKzEsOSBAQAorPHN0eWxlPnRlbmJ5dGVzIHs8 L3N0eWxlPgorCitUaGlzIHRlc3QgdGlja2xlcyBhIHN1YnRsZSBvZmYtYnktb25lIGJ1ZyBpbiBo b3cgV2ViS2l0J3MgQ1NTIGxleGVyCitoYW5kbGVzIGVuZCBvZiBidWZmZXIgY29uZGl0aW9ucy48 cD4KKworVGhlIGNvbnRlbnRzIG9mIHRoZSBzdHlsZSB0YWcgc2F0aXNmeSAobGVuZ3RoIG1vZCA4 ID0gMikgYW5kIGNvbnRhaW4gYW4KK3VuY2xvc2VkIGN1cmx5IGJyYWNlLiAgV2UgcGFzcyBpZiB3 ZSBkb24ndCBjcmFzaC48cD4KKworUEFTUwpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9DaGFuZ2VMb2cg Yi9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAyNTJjYjkyLi5iYmRlMzYwIDEwMDY0NAotLS0gYS9X ZWJDb3JlL0NoYW5nZUxvZworKysgYi9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBA CisyMDA5LTEwLTMwICBFdmFuIE1hcnRpbiAgPGV2YW5AY2hyb21pdW0ub3JnPgorCisgICAgICAg IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEZpeCBhbiBvZmYtYnktb25l IGluIHRoZSBDU1MgbGV4ZXIgdGhhdCBjYXVzZXMgbWVtb3J5IGNvcnJ1cHRpb24gaW4KKyAgICAg ICAgaGFyZC10by10cmlnZ2VyIGNpcmN1bXN0YW5jZXMuCisKKyAgICAgICAgaHR0cHM6Ly9idWdz LndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTMwODI3CisKKyAgICAgICAgVGVzdDogZmFzdC9j c3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC5odG1sCisKKyAgICAgICAgKiBjc3MvbWFrZXRva2VuaXpl cjogQWRkIGNvbW1lbnRzLCBmaXggb2ZmLWJ5LW9uZS4KKwogMjAwOS0xMC0zMCAgU2ViYXN0aWFu IERyw7ZnZSAgPHNlYmFzdGlhbi5kcm9lZ2VAY29sbGFib3JhLmNvLnVrPgogCiAgICAgICAgIFJl dmlld2VkIGJ5IEd1c3Rhdm8gTm9yb25oYS4KZGlmZiAtLWdpdCBhL1dlYkNvcmUvY3NzL21ha2V0 b2tlbml6ZXIgYi9XZWJDb3JlL2Nzcy9tYWtldG9rZW5pemVyCmluZGV4IGQxNGIzN2EuLjE5NjQ1 ZDcgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvY3NzL21ha2V0b2tlbml6ZXIKKysrIGIvV2ViQ29yZS9j c3MvbWFrZXRva2VuaXplcgpAQCAtNzMsMzAgKzczLDM2IEBAIHR5cGVkZWYgdW5zaWduZWQgaW50 IGZsZXhfdWludDMyX3Q7CiBFTkQKIH0KIAotCisjIFNraXAgb3ZlciB0aGUgZmxleCBvdXRwdXQg cHJvbG9ndWU6IHRoZSBhYm92ZSB0eXBlZGVmcywgZm9yd2FyZCBkZWNsYXJhdGlvbnMsIGV0Yy4K KyMgU3RvcCB3aGVuIHdlIGdldCB0byB0aGUgZGVjbGFyYXRpb25zIG9mIHRhYmxlcy4KIHdoaWxl ICg8PikgewogICAgIGxhc3QgaWYgL1lZX05VTV9SVUxFUy87CiB9CiAKKyMgRHVtcCB0aGUgZ2Vu ZXJhdGVkIHRhYmxlcy4gIC95eV9sYXN0X2FjY2VwdGluZy8gbWF0Y2hlcyB0aGUgZmlyc3QgZGVj bGFyYXRpb24gYWZ0ZXIgdGhlIHRhYmxlcy4KIHByaW50Owogd2hpbGUgKDw+KSB7CiAgICAgbGFz dCBpZiAveXlfbGFzdF9hY2NlcHRpbmcvOwogICAgIHByaW50OwogfQogCi0jIG1lZGlhIHF1ZXJ5 LCB0b2tlbml6ZXIgc3RhdGUgc3VwcG9ydAorIyBTa2lwIGRvd24gdGhlIHRoZSBkZWNsYXJhdGlv biBvZiB5eXRleHQ7IHRoZSBib2R5IG9mIHRoZSBmbGV4IG91dHB1dCBiZWdpbnMgYWZ0ZXIgaXQu CiB3aGlsZSAoPD4pIHsKICAgbGFzdCBpZiAveXl0ZXh0LzsKIH0KKyMgRHVtcCB0aGUgZGVmaW5p dGlvbnMgb2Ygc3RhdGVzIChJTklUSUFMLCBtZWRpYSBxdWVyeSwgdG9rZW5pemVyIHN0YXRlIHN1 cHBvcnQpLgogd2hpbGUgKDw+KSB7CiAgIGxhc3QgaWYgbm90ICgvZGVmaW5lLyB8fCAvbGluZS8p IDsKICAgcHJpbnQ7CiB9CiAKKyMgU2tpcCB0byBtYWluIHNjYW5uZXIgZnVuY3Rpb24uCiB3aGls ZSAoPD4pIHsKICAgICBsYXN0IGlmIC9eWVlfREVDTC87CiB9CiAKKyMgRHVtcCBtYWluIHNjYW5u ZXIgZGVjbGFyYXRpb25zLCBzdWJzdGl0dXRpbmcgaW4gb3VyIDE2LWJpdCBjaGFyYWN0ZXIgdHlw ZS4KKyMgRGVjbGFyYXRpb25zIGVuZCB3aXRoIHRoZSBkZWNsYXJhdGlvbiBtYXRjaGluZyAveXlf YWN0Ly4KIHByaW50Owogd2hpbGUgKDw+KSB7CiAgICAgcy9jaGFyL1VDaGFyLzsKQEAgLTEwNCwy MyArMTEwLDMyIEBAIHdoaWxlICg8PikgewogICAgIGxhc3QgaWYgL3l5X2FjdC87CiB9CiAKKyMg U2tpcCBwYXN0IGluaXRpYWxpemF0aW9uIGNvZGUsIGRvd24gdG8gbWFpbiBsb29wLgogd2hpbGUg KDw+KSB7CiAgICAgbGFzdCBpZiAvd2hpbGUgXCggMSBcKS87CiB9CiAKKyMgRHVtcCB0aGUgbWFp biBsb29wLCBza2lwcGluZyBvdmVyIGxhYmVscyB3ZSBkb24ndCB1c2UuCisjIFN0b3AgYmVmb3Jl IGR1bXBpbmcgdGhlIGVuZC1vZi1idWZmZXIgaGFuZGxpbmcsIGJlY2F1c2Ugd2Ugb3V0cHV0IG91 ciBvd24gY3VzdG9tIGVuZC1vZi1idWZmZXIgaGFuZGxpbmcuCiBwcmludDsKIHdoaWxlICg8Pikg ewogICAgIG5leHQgaWYgL155eV9tYXRjaDovOwogICAgIG5leHQgaWYgL15kb19hY3Rpb246LzsK ICAgICBsYXN0IGlmIC9ZWV9FTkRfT0ZfQlVGRkVSLzsKKyAgICBpZiAoL15jYXNlIFlZX1NUQVRF X0VPRlwoSU5JVElBTFwpOi8pIHsKKyAgICAgICAgcHJpbnQgImNhc2UgWVlfRU5EX09GX0JVRkZF UjpcbiI7CisgICAgICAgICMgZmxleCBvdXRwdXRzIGEgdG9uIG9mIGxvZ2ljIHJlbGF0ZWQgdG8g ZW5kLW9mLWJ1ZmZlciBoYW5kbGluZzsKKyAgICAgICAgIyB3ZSBqdXN0IHdhbnQgdGhlIG5vcm1h bCB0ZXJtaW5hdGlvbiBidXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRvIGJhY2sgdXAgdG8gYmVo aW5kCisgICAgICAgICMgdGhlIHRlcm1pbmF0aW5nIGRvdWJsZS1OVUwgc28gdGhhdCBzdWJzZXF1 ZW50IGNhbGxzIHRvIGZsZXggd2lsbCBoYXZlIHRoZSBwb2ludGVycyBpbiBvcmRlci4KKyAgICAg ICAgcHJpbnQgIlx0eXlfY19idWZfcC0tO1xuIjsKKyAgICB9CiAgICAgcHJpbnQ7Ci0gICAgcHJp bnQgImNhc2UgWVlfRU5EX09GX0JVRkZFUjpcbiIgaWYgL15jYXNlIFlZX1NUQVRFX0VPRlwoSU5J VElBTFwpOi87CiB9CiAKKyMgU2tpcCBvdmVyIHRoZSBlbmQtb2YtYnVmZmVyIGhhbmRsaW5nOyBk dW1wIHRoZSByZXN0IG9mIHRoZSBmdW5jdGlvbi4KIHdoaWxlICg8PikgewogICAgIGxhc3QgaWYg L2RlZmF1bHQ6LzsKIH0KLQogcHJpbnQ7CiB3aGlsZSAoPD4pIHsKICAgICBwcmludDs= 42334 2009-11-02 12:23:59 -0800 2009-11-03 10:37:47 -0800 patch and layout test bug-30827-20091102122352.patch text/plain 4682 evan ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBmODBkZmY4Li44ZmNkYzdjIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMDktMTAt MzAgIEV2YW4gTWFydGluICA8ZXZhbkBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQSB0ZXN0IHRoYXQgcmVwcm9kdWNlcyBhIGhh cmQtdG8tdHJpZ2dlciBtZW1vcnkgY29ycnVwdGlvbiBpbiB0aGUKKyAgICAgICAgQ1NTIGxleGVy LgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zMDgy NworCisgICAgICAgICogZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC5odG1sOiBBZGRlZC4K KwogMjAwOS0xMS0wMiAgUm9sYW5kIFN0ZWluZXIgIDxyb2xhbmRzdGVpbmVyQGNocm9taXVtLm9y Zz4KIAogICAgICAgICBSZXZpZXdlZCBieSBEYXZlIEh5YXR0LgpkaWZmIC0tZ2l0IGEvTGF5b3V0 VGVzdHMvZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC1leHBlY3RlZC50eHQgYi9MYXlvdXRU ZXN0cy9mYXN0L2Nzcy9lbmQtb2YtYnVmZmVyLWNyYXNoLWV4cGVjdGVkLnR4dApuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi40MGIwN2FiCi0tLSAvZGV2L251bGwKKysrIGIvTGF5 b3V0VGVzdHMvZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC1leHBlY3RlZC50eHQKQEAgLTAs MCArMSwzIEBACitUaGlzIHRlc3QgdGlja2xlcyBhIHN1YnRsZSBvZmYtYnktb25lIGJ1ZyBpbiBo b3cgdGhlIENTUyBsZXhlciBoYW5kbGVzIGVuZCBvZiBidWZmZXIgY29uZGl0aW9ucy4gVGhlIGNv bnRlbnRzIG9mIHRoZSBzdHlsZSB0YWcgc2F0aXNmeSAobGVuZ3RoIG1vZCA4ID0gMikgYW5kIGNv bnRhaW4gYW4gdW5jbG9zZWQgY3VybHkgYnJhY2UuIFdlIHBhc3MgaWYgd2UgZG9uJ3QgY3Jhc2gu CisKK1BBU1MKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3QvY3NzL2VuZC1vZi1idWZmZXIt Y3Jhc2guaHRtbCBiL0xheW91dFRlc3RzL2Zhc3QvY3NzL2VuZC1vZi1idWZmZXItY3Jhc2guaHRt bApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi42ZjY5ZTgzCi0tLSAvZGV2L251 bGwKKysrIGIvTGF5b3V0VGVzdHMvZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC5odG1sCkBA IC0wLDAgKzEsMTIgQEAKKzxzY3JpcHQ+CitpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVy KQorICAgIGxheW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKKzwvc2NyaXB0PgorCis8 c3R5bGU+dGVuYnl0ZXMgezwvc3R5bGU+CisKKzxwPlRoaXMgdGVzdCB0aWNrbGVzIGEgc3VidGxl IG9mZi1ieS1vbmUgYnVnIGluIGhvdyB0aGUgQ1NTIGxleGVyIGhhbmRsZXMgZW5kCitvZiBidWZm ZXIgY29uZGl0aW9ucy4gIFRoZSBjb250ZW50cyBvZiB0aGUgc3R5bGUgdGFnIHNhdGlzZnkgKGxl bmd0aCBtb2QgOCA9IDIpCithbmQgY29udGFpbiBhbiB1bmNsb3NlZCBjdXJseSBicmFjZS4gIFdl IHBhc3MgaWYgd2UgZG9uJ3QgY3Jhc2guPC9wPgorCis8cD5QQVNTPC9wPgpkaWZmIC0tZ2l0IGEv V2ViQ29yZS9DaGFuZ2VMb2cgYi9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCA0Y2U0ZjI4Li4yZWUx YTExIDEwMDY0NAotLS0gYS9XZWJDb3JlL0NoYW5nZUxvZworKysgYi9XZWJDb3JlL0NoYW5nZUxv ZwpAQCAtMSwzICsxLDE2IEBACisyMDA5LTEwLTMwICBFdmFuIE1hcnRpbiAgPGV2YW5AY2hyb21p dW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IEZpeCBhbiBvZmYtYnktb25lIGluIHRoZSBDU1MgbGV4ZXIgdGhhdCBjYXVzZXMgbWVtb3J5IGNv cnJ1cHRpb24gaW4KKyAgICAgICAgaGFyZC10by10cmlnZ2VyIGNpcmN1bXN0YW5jZXMuCisKKyAg ICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTMwODI3CisKKyAg ICAgICAgVGVzdDogZmFzdC9jc3MvZW5kLW9mLWJ1ZmZlci1jcmFzaC5odG1sCisKKyAgICAgICAg KiBjc3MvbWFrZXRva2VuaXplcjogQWRkIGNvbW1lbnRzLCBmaXggb2ZmLWJ5LW9uZS4KKwogMjAw OS0xMS0wMSAgS2VsbHkgTm9ydG9uICA8a25vcnRvbkBnb29nbGUuY29tPgogCiAgICAgICAgIFJl dmlld2VkIGJ5IFRpbW90aHkgSGF0Y2hlci4KZGlmZiAtLWdpdCBhL1dlYkNvcmUvY3NzL21ha2V0 b2tlbml6ZXIgYi9XZWJDb3JlL2Nzcy9tYWtldG9rZW5pemVyCmluZGV4IGQxNGIzN2EuLmVmYWMz YzYgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvY3NzL21ha2V0b2tlbml6ZXIKKysrIGIvV2ViQ29yZS9j c3MvbWFrZXRva2VuaXplcgpAQCAtNzMsMzAgKzczLDM2IEBAIHR5cGVkZWYgdW5zaWduZWQgaW50 IGZsZXhfdWludDMyX3Q7CiBFTkQKIH0KIAotCisjIFNraXAgb3ZlciB0aGUgZmxleCBvdXRwdXQg cHJvbG9ndWU6IHRoZSBhYm92ZSB0eXBlZGVmcywgZm9yd2FyZCBkZWNsYXJhdGlvbnMsIGV0Yy4K KyMgU3RvcCB3aGVuIHdlIGdldCB0byB0aGUgZGVjbGFyYXRpb25zIG9mIHRhYmxlcy4KIHdoaWxl ICg8PikgewogICAgIGxhc3QgaWYgL1lZX05VTV9SVUxFUy87CiB9CiAKKyMgRHVtcCB0aGUgZ2Vu ZXJhdGVkIHRhYmxlcy4gIC95eV9sYXN0X2FjY2VwdGluZy8gbWF0Y2hlcyB0aGUgZmlyc3QgZGVj bGFyYXRpb24gYWZ0ZXIgdGhlIHRhYmxlcy4KIHByaW50Owogd2hpbGUgKDw+KSB7CiAgICAgbGFz dCBpZiAveXlfbGFzdF9hY2NlcHRpbmcvOwogICAgIHByaW50OwogfQogCi0jIG1lZGlhIHF1ZXJ5 LCB0b2tlbml6ZXIgc3RhdGUgc3VwcG9ydAorIyBTa2lwIGRvd24gdGhlIHRoZSBkZWNsYXJhdGlv biBvZiB5eXRleHQ7IHRoZSBib2R5IG9mIHRoZSBmbGV4IG91dHB1dCBiZWdpbnMgYWZ0ZXIgaXQu CiB3aGlsZSAoPD4pIHsKICAgbGFzdCBpZiAveXl0ZXh0LzsKIH0KKyMgRHVtcCB0aGUgZGVmaW5p dGlvbnMgb2Ygc3RhdGVzIChJTklUSUFMLCBtZWRpYSBxdWVyeSwgdG9rZW5pemVyIHN0YXRlIHN1 cHBvcnQpLgogd2hpbGUgKDw+KSB7CiAgIGxhc3QgaWYgbm90ICgvZGVmaW5lLyB8fCAvbGluZS8p IDsKICAgcHJpbnQ7CiB9CiAKKyMgU2tpcCB0byBtYWluIHNjYW5uZXIgZnVuY3Rpb24uCiB3aGls ZSAoPD4pIHsKICAgICBsYXN0IGlmIC9eWVlfREVDTC87CiB9CiAKKyMgRHVtcCBtYWluIHNjYW5u ZXIgZGVjbGFyYXRpb25zLCBzdWJzdGl0dXRpbmcgaW4gb3VyIDE2LWJpdCBjaGFyYWN0ZXIgdHlw ZS4KKyMgRGVjbGFyYXRpb25zIGVuZCB3aXRoIHRoZSBkZWNsYXJhdGlvbiBtYXRjaGluZyAveXlf YWN0Ly4KIHByaW50Owogd2hpbGUgKDw+KSB7CiAgICAgcy9jaGFyL1VDaGFyLzsKQEAgLTEwNCwy MyArMTEwLDM0IEBAIHdoaWxlICg8PikgewogICAgIGxhc3QgaWYgL3l5X2FjdC87CiB9CiAKKyMg U2tpcCBwYXN0IGluaXRpYWxpemF0aW9uIGNvZGUsIGRvd24gdG8gbWFpbiBsb29wLgogd2hpbGUg KDw+KSB7CiAgICAgbGFzdCBpZiAvd2hpbGUgXCggMSBcKS87CiB9CiAKKyMgRHVtcCB0aGUgbWFp biBsb29wLCBza2lwcGluZyBvdmVyIGxhYmVscyB3ZSBkb24ndCB1c2UuCisjIFN0b3AgYmVmb3Jl IGR1bXBpbmcgdGhlIGVuZC1vZi1idWZmZXIgaGFuZGxpbmcsIGJlY2F1c2Ugd2Ugb3V0cHV0IG91 ciBvd24gY3VzdG9tIGVuZC1vZi1idWZmZXIgaGFuZGxpbmcuCiBwcmludDsKIHdoaWxlICg8Pikg ewogICAgIG5leHQgaWYgL155eV9tYXRjaDovOwogICAgIG5leHQgaWYgL15kb19hY3Rpb246LzsK ICAgICBsYXN0IGlmIC9ZWV9FTkRfT0ZfQlVGRkVSLzsKKyAgICBpZiAoL15jYXNlIFlZX1NUQVRF X0VPRlwoSU5JVElBTFwpOi8pIHsKKyAgICAgICAgcHJpbnQgImNhc2UgWVlfRU5EX09GX0JVRkZF UjpcbiI7CisgICAgICAgICMgZmxleCBvdXRwdXRzIGEgdG9uIG9mIGxvZ2ljIHJlbGF0ZWQgdG8g ZW5kLW9mLWJ1ZmZlciBoYW5kbGluZzsgd2UganVzdCB3YW50IHRvIGZhbGwgdGhyb3VnaCB0bwor ICAgICAgICAjIHRoZSB5eXRlcm1pbmF0ZSgpIGZvdW5kIGluIG90aGVyIEVPRiBzdGF0ZXMuICBC dXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRvIGJhY2sgdXAgdG8gYmVoaW5kCisgICAgICAgICMg dGhlIHRlcm1pbmF0aW5nIGRvdWJsZS1OVUwgc28gdGhhdCBzdWJzZXF1ZW50IGNhbGxzIHRvIGZs ZXggd2lsbCBoYXZlIHRoZSBwb2ludGVycyBpbiBvcmRlciwKKyAgICAgICAgIyBzbyB0aGlzIGxv Z2ljIGlzIGEgcmVkdWN0aW9uIG9mIHRoZSBub3JtYWwgZmxleC1nZW5lcmF0ZWQgWVlfRU5EX09G X0JVRkZFUiBjb2RlLgorICAgICAgICBwcmludCAiXHR5eV9jX2J1Zl9wID0geXlfY3AgLSAxO1xu IjsKKyAgICAgICAgcHJpbnQgIlx0eXlfY3AgPSB5eV9jX2J1Zl9wO1xuIjsKKyAgICB9CiAgICAg cHJpbnQ7Ci0gICAgcHJpbnQgImNhc2UgWVlfRU5EX09GX0JVRkZFUjpcbiIgaWYgL15jYXNlIFlZ X1NUQVRFX0VPRlwoSU5JVElBTFwpOi87CiB9CiAKKyMgU2tpcCBvdmVyIHRoZSBlbmQtb2YtYnVm ZmVyIGhhbmRsaW5nOyBkdW1wIHRoZSByZXN0IG9mIHRoZSBmdW5jdGlvbi4KIHdoaWxlICg8Pikg ewogICAgIGxhc3QgaWYgL2RlZmF1bHQ6LzsKIH0KLQogcHJpbnQ7CiB3aGlsZSAoPD4pIHsKICAg ICBwcmludDs=