36647 2010-03-26 01:25:24 -0700 fast/loader/stateobjects/replacestate-then-pushstate.html fails intermittently on all bots 2010-04-02 23:00:40 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 36779 1 eric fishd abarth beidson commit-queue eric fishd sam webkit.review.bot oldest_to_newest 204466 0 eric 2010-03-26 01:25:24 -0700 fast/loader/stateobjects/replacestate-then-pushstate.html failed on Snow Leopard Release Bot The dump looks like DRT is confused and dumping the wrong test (maybe the previous test?) http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/stateobjects/replacestate-then-pushstate.html http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r56612%20(7249)/fast/loader/stateobjects/replacestate-then-pushstate-diffs.txt --- /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release-tests/build/layout-test-results/fast/loader/stateobjects/replacestate-then-pushstate-expected.txt 2010-03-26 01:10:32.000000000 -0700 +++ /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release-tests/build/layout-test-results/fast/loader/stateobjects/replacestate-then-pushstate-actual.txt 2010-03-26 01:10:32.000000000 -0700 @@ -1,13 +1,17 @@ -This test does the following: --Makes a call to replaceState() --Makes sure the history length is correct --Makes a call to pushState() --Makes sure the history length is correct --Goes back, and makes sure the popstate event is correct --Goes forward, and makes sure the popstate event is correct - -History length is 1 -History length is 2 -State popped - OriginalHistoryItem (type string) -State popped - NewHistoryItem (type string) - +layer at (0,0) size 800x600 + RenderView at (0,0) size 800x600 +layer at (0,0) size 800x600 + RenderBlock {HTML} at (0,0) size 800x600 + RenderBody {BODY} at (8,8) size 784x584 + RenderText {#text} at (0,140) size 70x18 + text run at (0,140) width 70: "default text" + RenderText {#text} at (70,140) size 4x18 + text run at (70,140) width 4: " " + RenderPartObject {IFRAME} at (74,0) size 304x154 [border: (2px inset #000000)] + layer at (0,0) size 300x150 + RenderView at (0,0) size 300x150 + layer at (0,0) size 300x150 + RenderBlock {HTML} at (0,0) size 300x150 + RenderBody {BODY} at (8,8) size 284x134 + RenderText {#text} at (0,0) size 21x18 + text run at (0,0) width 21: "foo" 204616 1 beidson 2010-03-26 09:26:44 -0700 Yes, it is dumping the wrong test. Yes, this has been happening with scattered tests that I added, sometimes very recently and sometimes many months ago. No, I have no idea how to explore this especially since they're often very rare failures on the bots and I can never reproduce locally. In other words... *sigh* 205639 2 eric 2010-03-29 13:29:02 -0700 failed again: http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r56733%20(7364)/fast/loader/stateobjects/replacestate-then-pushstate-diffs.txt Possibly related ASSERT hit on Leopard in bug 36779. 205797 3 eric 2010-03-29 19:05:45 -0700 Failed on the Leopard Commit bot just now too: https://bugs.webkit.org/show_bug.cgi?id=30144#c66 206763 4 eric 2010-03-31 15:32:42 -0700 It appears to be failing on the Tiger bot as well: http://build.webkit.org/results/Tiger%20Intel%20Release/r56871%20(10265)/fast/loader/stateobjects/replacestate-then-pushstate-pretty-diff.html Seems we should skip/disable this test since it's failing on at least 3 bots. 206769 5 beidson 2010-03-31 15:42:41 -0700 Until now, I wasn't aware this was failing every time on the bots. 206770 6 beidson 2010-03-31 15:43:42 -0700 (In reply to comment #5) > Until now, I wasn't aware this was failing every time on the bots. Checking it myself, it appears it is not failing every time. 206785 7 eric 2010-03-31 16:01:33 -0700 Correct. It is not failing consistently on any machine to my knowledge. My apologies if my statements led you to believe such. This is however a common failure, just not consistent. :( 207572 8 eric 2010-04-01 18:20:21 -0700 The commit-queue just hit this too: https://bugs.webkit.org/show_bug.cgi?id=36369#c4 207788 9 eric 2010-04-02 01:09:38 -0700 Tiger hit this several times today. Seems we should disable this test for all bots. Unless you have a fix in the pipeline Brady? 207885 10 beidson 2010-04-02 09:37:58 -0700 (In reply to comment #9) > Tiger hit this several times today. Seems we should disable this test for all > bots. Unless you have a fix in the pipeline Brady? Is this one of the tests that's "failing" by showing the output from the previous test? ie - the test itself isn't necessarily failing but being polluted by something prior. Here's my dilemma. I would love to pour in the time to figure out what is wrong with the test harness, but I am not an expert at the test harness and would be spinning my wheels, and don't have time right now to spin my wheels. We can't just keep disabling tests that only have intermittent failures and (apparently) only on the bots. If I can never reproduce locally, I can never explore it. But it we just keep disabling test-after-test, then we lose the test coverage for when it really breaks 100% of the time, even for individual contributors on their own machines. I would love to hear referrals for people who are truly experts at run-webkit-tests and DRT, and to work with them to figure out what is going on. 207892 11 abarth 2010-04-02 09:53:39 -0700 The flip side of that argument is that we have >13k tests. Because the bots (Tiger and Snow Leopard especially) are constantly red, we become blind to failures and miss real regressions. If we lose 0.01% of our tests, that's a net win for the project. However, in many cases, we've been able to keep the test coverage and remove the flakiness, even with no access to the failures locally. For example, last night I fixed a test that was failing only on Tiger with no ability to reproduce the failure myself. It just requires effort. I don't have visibility into the other demands on your time. It's entirely possible you have more important things to be working on. However, that doesn't means we should impose these costs on the rest of the project. 207895 12 abarth 2010-04-02 09:57:52 -0700 > Is this one of the tests that's "failing" by showing the output from the > previous test? ie - the test itself isn't necessarily failing but being > polluted by something prior. Here's the failure pretty diff: http://build.webkit.org/results/Tiger%20Intel%20Release/r57003%20(10355)/fast/loader/stateobjects/replacestate-then-pushstate-pretty-diff.html 207897 13 abarth 2010-04-02 10:01:17 -0700 By way of context, this test has failed on 8 of the last 10 Tiger bot runs. It's one of three tests that prevent this bot from being green and put under the protection of SheriffBot (who will help prevent future real regressions). Three tests are 0.023% of tests. 207908 14 beidson 2010-04-02 10:13:23 -0700 (In reply to comment #11) > The flip side of that argument is that we have >13k tests. Because the bots > (Tiger and Snow Leopard especially) are constantly red, we become blind to > failures and miss real regressions. If we lose 0.01% of our tests, that's a > net win for the project. Unless the feature is new with only an initial batch of tests and disabling one of the tests would result in the loss of ~10% of the test coverage for a reasonably complicated mechanism. > However, in many cases, we've been able to keep the test coverage and remove > the flakiness, even with no access to the failures locally. For example, last > night I fixed a test that was failing only on Tiger with no ability to > reproduce the failure myself. It just requires effort. Wildly varying amounts of effort - I have spent time on this already and no one I've reached out to has decided it was worth helping. (In reply to comment #12) > > Is this one of the tests that's "failing" by showing the output from the > > previous test? ie - the test itself isn't necessarily failing but being > > polluted by something prior. > > Here's the failure pretty diff: > > http://build.webkit.org/results/Tiger%20Intel%20Release/r57003%20(10355)/fast/loader/stateobjects/replacestate-then-pushstate-pretty-diff.html This diff appears to be the previous test (fast/loader/replacestate-in-iframe.html) dumping into the test that the bots see as failing. This appears to best a test harness problem that I would love help tracking down, because apparently every other test I've added lately has been affected by this problem somehow. Any ideas? (CC'ing Darin Fisher, who added the test that is causing the forward failure) 207916 15 fishd 2010-04-02 10:21:23 -0700 This test is also failing intermittently on the chromium bots. I'll investigate. 207919 16 abarth 2010-04-02 10:23:39 -0700 I can read up on how this feature is supposed to work, but the first step I would try to black-box debug this issue is to insert a trivial test between the previous test and this one. That way we can see whether the previous test is leaking state forward or this test is pulling previous state forward. 207923 17 beidson 2010-04-02 10:27:05 -0700 (In reply to comment #16) > I can read up on how this feature is supposed to work, but the first step I > would try to black-box debug this issue is to insert a trivial test between the > previous test and this one. That way we can see whether the previous test is > leaking state forward or this test is pulling previous state forward. That is a good idea - except since I have never been able to reproduce this locally, and I haven't heard from any other fellow WebKit developers nearby about this test failing for them, this appears to be a bot-only issue and your experiment would require checking in a dummy test for experimentation on the bots. Which (I don't believe) there is any precedent for. 207925 18 abarth 2010-04-02 10:30:04 -0700 > Which (I don't believe) there is any precedent for. Right, I'm proposing adding a new test to debug this on the bots. Given that it fails about 80% of the time, we should get our answer in a few cycles. I've done similar experiments before to solve bot-only issues. In any case, I don't think it's a big problem to add more tests. 207926 19 abarth 2010-04-02 10:31:03 -0700 Reading replacestate-then-pushstate.html, I wonder if the call to history.back() is causing problems, for example if the history timer is racing with some other asynchronous bit? An interesting clue is that the previous test results are dumped as a render tree and not as text. 207929 20 beidson 2010-04-02 10:35:17 -0700 (In reply to comment #19) > Reading replacestate-then-pushstate.html, I wonder if the call to > history.back() is causing problems, for example if the history timer is racing > with some other asynchronous bit? An interesting clue is that the previous > test results are dumped as a render tree and not as text. Which seems to always be the case in these types of failures that we've seen lately. Because of the varying and async nature of the test it is - of course - a waitUntilDone test. And it seems to me that DRT should have already done its dumping for the previous test before the new test is started, then wiped that out. With those two understandings, I'm not sure what asynchronous bit might exist here. 207930 21 abarth 2010-04-02 10:39:24 -0700 > Which seems to always be the case in these types of failures that we've seen > lately. Do you have links to other failures of this kind? I'm new to the flaky test party. > Because of the varying and async nature of the test it is - of course - a > waitUntilDone test. Both this test and the previous test are waitUntilDone. > And it seems to me that DRT should have already done its dumping for the > previous test before the new test is started, then wiped that out. Right. The previous test passes, so DRT has decided it's happy with what happened there. > With those two understandings, I'm not sure what asynchronous bit might exist > here. When I've seen leakages before, it's because a test is running code after DRT thinks that the test is done. For example, if you call alert in your unload handler, the alert will be recorded for the next test. Maybe popstate has similar timing? Is that called when you navigate away from a page? I guess I should read up on how this API works. 207937 22 abarth 2010-04-02 10:48:40 -0700 Woah, I'm now convinced that http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/stateobjects/replacestate-in-iframe.html is the problem. That test is nuts. We should run it in popup window. 207938 23 fishd 2010-04-02 10:50:43 -0700 I think this is probably related to the fact that we dispatch the PopStateEvent synchronously. In fast/loader/replacestate-in-iframe.html, the PopStateEvent occurs in an iframe, and it is from there that the test calls notifyDone(). I think I'm going to approach this problem by making the test less nutty ;-) 207962 24 beidson 2010-04-02 11:40:25 -0700 (In reply to comment #22) > Woah, I'm now convinced that > http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/stateobjects/replacestate-in-iframe.html > is the problem. That test is nuts. We should run it in popup window. I agree that test is nutty, and am glad Darin's looking into it. I'm still at a loss on this from the high run-webkit-tests + DRT level. Could you share your understanding of why Darin's test causes this to happen? And could we fix DRT + run-webkit-tests to handle Darin's test -as nutty as it is? :) I ask because - like I mentioned - this has come up a couple of time with bizarre loader tests I've added over the last few months and I *really* need the understanding of the root cause so I can go back and reenable disabled tests and fix other intermittent weirdness! 207995 25 eric 2010-04-02 12:20:31 -0700 I believe these are two of the tests Brady is referring to: http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/api-test-go-to-current-back-forward-item.html-disabled http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/api-test-new-window-data-load-base-url.html-disabled 207998 26 52435 fishd 2010-04-02 12:22:41 -0700 Created attachment 52435 v1 patch 208000 27 fishd 2010-04-02 12:26:51 -0700 (In reply to comment #24) > And could we fix DRT + run-webkit-tests to handle Darin's test -as nutty as it > is? :) I looked into this, and I'm not sure it is possible. In this case, the root cause of the bug is that onpopstate sometimes runs before the page is fully loaded. During onpopstate, I was calling notifyDone. As a result, when the page finally finishes loading, it ends up dumping the test results again. One way to avoid problems like this would be to create a new WebView for each test. 208001 28 beidson 2010-04-02 12:29:32 -0700 (In reply to comment #27) > (In reply to comment #24) > > And could we fix DRT + run-webkit-tests to handle Darin's test -as nutty as it > > is? :) > > I looked into this, and I'm not sure it is possible. In this case, the root > cause of the bug is that onpopstate sometimes runs before the page is fully > loaded. During onpopstate, I was calling notifyDone. As a result, when the > page finally finishes loading, it ends up dumping the test results again. > > One way to avoid problems like this would be to create a new WebView for each > test. Presumably we could make notifyDone() be a synchronous message to DRT meaning "Hey, test is over - RIGHT NOW" and DRT could cancel the load if its not done yet. I don't know how many other tests this would affect, but one might argue that those other tests are "wrong" 208002 29 52435 fishd 2010-04-02 12:29:46 -0700 Comment on attachment 52435 v1 patch Whoops, I just realized that this no longer tests the fix I was intending it to test! Doh! 208084 30 abarth 2010-04-02 15:03:30 -0700 BTW, new-run-webkit-tests support --run-singly, which I think uses a new DRT process for each test. 208085 31 eric 2010-04-02 15:11:01 -0700 "old-" run webkit-tests supports that too. :) 208200 32 52475 fishd 2010-04-02 20:16:10 -0700 Created attachment 52475 v2 patch 208203 33 52475 abarth 2010-04-02 20:38:15 -0700 Comment on attachment 52475 v2 patch LGTM, thanks. Sounds like a cool bug. 208215 34 fishd 2010-04-02 21:49:17 -0700 Landed as http://trac.webkit.org/changeset/57042 208234 35 webkit.review.bot 2010-04-02 22:59:32 -0700 http://trac.webkit.org/changeset/57042 might have broken Leopard Intel Debug (Tests) 208235 36 abarth 2010-04-02 23:00:40 -0700 It's really https://bugs.webkit.org/show_bug.cgi?id=36646. The failure rate from that test is insanely high. I've disabled it. 52435 2010-04-02 12:22:41 -0700 2010-04-02 20:16:10 -0700 v1 patch less_insane_1.txt text/plain 4362 fishd SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIExheW91dFRlc3Rz L0NoYW5nZUxvZwkocmV2aXNpb24gNTcwMTQpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdv cmtpbmcgY29weSkKQEAgLTEsMyArMSwxNSBAQAorMjAxMC0wNC0wMiAgRGFyaW4gRmlzaGVyICA8 ZGFyaW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEp LgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zNjY0 NworICAgICAgICBNYWtlIHJlcGxhY2VzdGF0ZS1pbi1mcmFtZS5odG1sIGxlc3MgaW5zYW5lIGFu ZCBob3BlZnVsbHkgbm8gbG9uZ2VyIGZsYWt5LgorCisgICAgICAgICogZmFzdC9sb2FkZXIvc3Rh dGVvYmplY3RzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUtZXhwZWN0ZWQudHh0OgorICAgICAgICAq IGZhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLmh0bWw6Cisg ICAgICAgICogZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3Jlc291cmNlcy9yZXBsYWNlc3RhdGUt aW4taWZyYW1lLXdpbmRvdy1jaGlsZC5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBmYXN0L2xvYWRl ci9zdGF0ZW9iamVjdHMvcmVzb3VyY2VzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUtd2luZG93Lmh0 bWw6IEFkZGVkLgorCiAyMDEwLTA0LTAyICBLZW50IFRhbXVyYSAgPHRrZW50QGNocm9taXVtLm9y Zz4KIAogICAgICAgICBSZXZpZXdlZCBieSBEYXJpbiBBZGxlci4KSW5kZXg6IExheW91dFRlc3Rz L2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLWV4cGVjdGVk LnR4dA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KLS0tIExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0 cy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gNTcwMTMpCisr KyBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcmVwbGFjZXN0YXRlLWluLWlm cmFtZS1leHBlY3RlZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTMsOSArMyw1IEBAIGZyYW1lICI8 IS0tZnJhbWVQYXRoIC8vPCEtLWZyYW1lMC0tPi0tPiIKIEFMRVJUOiBOYXZpZ2F0aW5nIGJhY2su Li4KIG1haW4gZnJhbWUgLSBoYXMgMSBvbnVubG9hZCBoYW5kbGVyKHMpCiBmcmFtZSAiPCEtLWZy YW1lUGF0aCAvLzwhLS1mcmFtZTAtLT4tLT4iIC0gaGFzIDEgb251bmxvYWQgaGFuZGxlcihzKQot ZGVmYXVsdCB0ZXh0IAotCi0tLS0tLS0tLQotRnJhbWU6ICc8IS0tZnJhbWVQYXRoIC8vPCEtLWZy YW1lMC0tPi0tPicKLS0tLS0tLS0tCi1mb28KK0FMRVJUOiBvbnBvcHN0YXRlIGluIGNoaWxkIGZy YW1lCitQQVNTCkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcmVw bGFjZXN0YXRlLWluLWlmcmFtZS5odG1sDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gTGF5b3V0VGVzdHMvZmFz dC9sb2FkZXIvc3RhdGVvYmplY3RzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUuaHRtbAkocmV2aXNp b24gNTcwMTMpCisrKyBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcmVwbGFj ZXN0YXRlLWluLWlmcmFtZS5odG1sCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMyICsxLDI5IEBACiA8 c2NyaXB0PgotaWYgKHBhcmVudCA9PSB3aW5kb3cgJiYgd2luZG93LmxheW91dFRlc3RDb250cm9s bGVyKSB7CitpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKSB7CiAgIGxheW91dFRlc3RD b250cm9sbGVyLmR1bXBBc1RleHQoKTsKLSAgbGF5b3V0VGVzdENvbnRyb2xsZXIuZHVtcENoaWxk RnJhbWVzQXNUZXh0KCk7CisgIGxheW91dFRlc3RDb250cm9sbGVyLnNldENhbk9wZW5XaW5kb3dz KCk7CiAgIGxheW91dFRlc3RDb250cm9sbGVyLndhaXRVbnRpbERvbmUoKTsKIH0KIAotZnVuY3Rp b24gcnVuVGVzdCgpIHsKLSAgZnJhbWVzWzBdLmhpc3RvcnkucmVwbGFjZVN0YXRlKCJmb28iLCAi Zm9vIiwgIiNmb28iKTsKLSAgbG9jYXRpb24gPSAicmVzb3VyY2VzL25hdmlnYXRlLWJhY2suaHRt bCI7Ci19Ci0KLW9ucG9wc3RhdGUgPSBmdW5jdGlvbihlKSB7Ci0gIGRvY3VtZW50LmJvZHkuaW5u ZXJUZXh0ID0gZS5zdGF0ZTsKK2Z1bmN0aW9uIG5vdGlmeURvbmUoKSB7CisgIGRvY3VtZW50LmJv ZHkuaW5uZXJUZXh0ID0gIlBBU1MiOwogICBpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVy KQogICAgIGxheW91dFRlc3RDb250cm9sbGVyLm5vdGlmeURvbmUoKTsKIH0KIAogb25sb2FkID0g ZnVuY3Rpb24oKSB7Ci0gIGlmIChwYXJlbnQgPT0gd2luZG93KSB7Ci0gICAgdmFyIGYgPSBkb2N1 bWVudC5jcmVhdGVFbGVtZW50KCJpZnJhbWUiKTsKLSAgICBmLnNyYyA9IGxvY2F0aW9uOwotICAg IGYub25sb2FkID0gZnVuY3Rpb24oKSB7IHNldFRpbWVvdXQocnVuVGVzdCwgMCk7IH07Ci0gICAg ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChmKTsKLSAgfQotfQorICB2YXIgd2luID0gd2luZG93 Lm9wZW4oInJlc291cmNlcy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLXdpbmRvdy5odG1sIik7Cisg IHdpbi5vbmxvYWQgPSBmdW5jdGlvbigpIHsKKyAgICAvLyBBdm9pZCByZXBlYXRpbmcgdGhlIHRl c3QuCisgICAgZGVsZXRlIHdpbi5vbmxvYWQ7CiAKLW9udW5sb2FkID0gZnVuY3Rpb24oKSB7Ci0g IC8vIGRpc2FibGUgcGFnZSBjYWNoZQorICAgIC8vIEFsbG93IHBhZ2UgbG9hZCB0byBjb21wbGV0 ZSBiZWZvcmUgd2Ugc3RhcnQgbmF2aWdhdGluZyBhZ2Fpbi4gIE90aGVyd2lzZSwKKyAgICAvLyBu YXZpZ2F0aW5nIHRvIG5hdmlnYXRlLWJhY2suaHRtbCB3b3VsZCBub3QgY3JlYXRlIGEgbmV3IGhp c3RvcnkgaXRlbS4KKyAgICBzZXRUaW1lb3V0KGZ1bmN0aW9uKCkgeworICAgICAgd2luLmZyYW1l c1swXS5oaXN0b3J5LnJlcGxhY2VTdGF0ZSgiUEFTUyIsICJQQVNTIiwgIiNQQVNTIik7CisgICAg ICB3aW4ubG9jYXRpb24gPSAicmVzb3VyY2VzL25hdmlnYXRlLWJhY2suaHRtbCI7CisgICAgfSwg MCk7CisgIH0KIH0KIDwvc2NyaXB0PgotPGJvZHk+ZGVmYXVsdCB0ZXh0PC9ib2R5PgorPGJvZHk+ RkFJTDwvYm9keT4KSW5kZXg6IExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9y ZXNvdXJjZXMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS13aW5kb3ctY2hpbGQuaHRtbA0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KLS0tIExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXNvdXJjZXMv cmVwbGFjZXN0YXRlLWluLWlmcmFtZS13aW5kb3ctY2hpbGQuaHRtbAkocmV2aXNpb24gMCkKKysr IExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXNvdXJjZXMvcmVwbGFjZXN0 YXRlLWluLWlmcmFtZS13aW5kb3ctY2hpbGQuaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwx MiBAQAorPHNjcmlwdD4KK29ucG9wc3RhdGUgPSBmdW5jdGlvbihlKSB7CisgIGFsZXJ0KCJvbnBv cHN0YXRlIGluIGNoaWxkIGZyYW1lIik7CisKKyAgdG9wLm9wZW5lci5ub3RpZnlEb25lKCk7Cisg IHRvcC5jbG9zZSgpOworfQorCitvbnVubG9hZCA9IGZ1bmN0aW9uKCkgeworICAvLyBkaXNhYmxl IHBhZ2UgY2FjaGUKK30KKzwvc2NyaXB0PgpJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9sb2FkZXIv c3RhdGVvYmplY3RzL3Jlc291cmNlcy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLXdpbmRvdy5odG1s DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQotLS0gTGF5b3V0VGVzdHMvZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3Jl c291cmNlcy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLXdpbmRvdy5odG1sCShyZXZpc2lvbiAwKQor KysgTGF5b3V0VGVzdHMvZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3Jlc291cmNlcy9yZXBsYWNl c3RhdGUtaW4taWZyYW1lLXdpbmRvdy5odG1sCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDYgQEAK KzxzY3JpcHQ+CitvbnVubG9hZCA9IGZ1bmN0aW9uKCkgeworICAvLyBkaXNhYmxlIHBhZ2UgY2Fj aGUKK30KKzwvc2NyaXB0PgorPGJvZHk+PGlmcmFtZSBzcmM9InJlcGxhY2VzdGF0ZS1pbi1pZnJh bWUtd2luZG93LWNoaWxkLmh0bWwiPjwvYm9keT4K 52475 2010-04-02 20:16:10 -0700 2010-04-02 21:50:03 -0700 v2 patch less_insane_2.txt text/plain 4658 fishd SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIExheW91dFRlc3Rz L0NoYW5nZUxvZwkocmV2aXNpb24gNTcwMzkpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdv cmtpbmcgY29weSkKQEAgLTEsMyArMSwxNSBAQAorMjAxMC0wNC0wMiAgRGFyaW4gRmlzaGVyICA8 ZGFyaW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEp LgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zNjY0 NworICAgICAgICBNYWtlIHJlcGxhY2VzdGF0ZS1pbi1mcmFtZS5odG1sIGxlc3MgaW5zYW5lIGFu ZCBob3BlZnVsbHkgbm8gbG9uZ2VyIGZsYWt5LgorCisgICAgICAgICogZmFzdC9sb2FkZXIvc3Rh dGVvYmplY3RzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUtZXhwZWN0ZWQudHh0OgorICAgICAgICAq IGZhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLmh0bWw6Cisg ICAgICAgICogZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3Jlc291cmNlcy9yZXBsYWNlc3RhdGUt aW4taWZyYW1lLXdpbmRvdy1jaGlsZC5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBmYXN0L2xvYWRl ci9zdGF0ZW9iamVjdHMvcmVzb3VyY2VzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUtd2luZG93Lmh0 bWw6IEFkZGVkLgorCiAyMDEwLTA0LTAyICBBbmRyZXcgU2NoZXJrdXMgIDxzY2hlcmt1c0BjaHJv bWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgRXJpYyBDYXJsc29uIGFuZCBFcmljIFNl aWRlbC4KSW5kZXg6IExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXBsYWNl c3RhdGUtaW4taWZyYW1lLWV4cGVjdGVkLnR4dA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIExheW91dFRlc3Rz L2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXBsYWNlc3RhdGUtaW4taWZyYW1lLWV4cGVjdGVk LnR4dAkocmV2aXNpb24gNTcwMTMpCisrKyBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9i amVjdHMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS1leHBlY3RlZC50eHQJKHdvcmtpbmcgY29weSkK QEAgLTMsOSArMyw1IEBAIGZyYW1lICI8IS0tZnJhbWVQYXRoIC8vPCEtLWZyYW1lMC0tPi0tPiIK IEFMRVJUOiBOYXZpZ2F0aW5nIGJhY2suLi4KIG1haW4gZnJhbWUgLSBoYXMgMSBvbnVubG9hZCBo YW5kbGVyKHMpCiBmcmFtZSAiPCEtLWZyYW1lUGF0aCAvLzwhLS1mcmFtZTAtLT4tLT4iIC0gaGFz IDEgb251bmxvYWQgaGFuZGxlcihzKQotZGVmYXVsdCB0ZXh0IAotCi0tLS0tLS0tLQotRnJhbWU6 ICc8IS0tZnJhbWVQYXRoIC8vPCEtLWZyYW1lMC0tPi0tPicKLS0tLS0tLS0tCi1mb28KK0FMRVJU OiBvbnBvcHN0YXRlCitQQVNTCkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9i amVjdHMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS5odG1sDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gTGF5b3V0 VGVzdHMvZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUuaHRt bAkocmV2aXNpb24gNTcwMTMpCisrKyBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVj dHMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS5odG1sCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMyICsx LDM5IEBACiA8c2NyaXB0PgotaWYgKHBhcmVudCA9PSB3aW5kb3cgJiYgd2luZG93LmxheW91dFRl c3RDb250cm9sbGVyKSB7CitpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKSB7CiAgIGxh eW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKLSAgbGF5b3V0VGVzdENvbnRyb2xsZXIu ZHVtcENoaWxkRnJhbWVzQXNUZXh0KCk7CisgIGxheW91dFRlc3RDb250cm9sbGVyLnNldENhbk9w ZW5XaW5kb3dzKCk7CiAgIGxheW91dFRlc3RDb250cm9sbGVyLndhaXRVbnRpbERvbmUoKTsKIH0K IAotZnVuY3Rpb24gcnVuVGVzdCgpIHsKLSAgZnJhbWVzWzBdLmhpc3RvcnkucmVwbGFjZVN0YXRl KCJmb28iLCAiZm9vIiwgIiNmb28iKTsKLSAgbG9jYXRpb24gPSAicmVzb3VyY2VzL25hdmlnYXRl LWJhY2suaHRtbCI7Ci19CisvLyBUaGlzIGlzIGEgdGVzdCB0aGF0IHJlcGxhY2VTdGF0ZSBjYWxs ZWQgb24gYW4gaW5uZXIgZnJhbWUgZG9lcyBub3QgbW9kaWZ5CisvLyB0aGUgaGlzdG9yeSBzdGF0 ZSBvZiB0aGUgdG9wIGZyYW1lLiAgVGhlIHRlc3QgYXNzZXJ0cyB0aGF0IHRoZSBpbm5lciBmcmFt ZQorLy8gcmVtYWlucyB0aGUgaW5uZXIgZnJhbWUgYW5kIGlzIG5vdCBwcm9tb3RlZCB0byBiZWNv bWUgdGhlIHRvcCBmcmFtZSBkdXJpbmcKKy8vIGhpc3RvcnkgdHJhdmVyc2FsIChvbiBuYXZpZ2F0 aW5nIGJhY2spLgorCit2YXIgdGVzdFdpbjsKKworZnVuY3Rpb24gbm90aWZ5RG9uZShyZXN1bHQp IHsKKyAgdGVzdFdpbi5jbG9zZSgpOworICBkZWxldGUgdGVzdFdpbjsKKworICBkb2N1bWVudC5i b2R5LmlubmVyVGV4dCA9IHJlc3VsdDsKIAotb25wb3BzdGF0ZSA9IGZ1bmN0aW9uKGUpIHsKLSAg ZG9jdW1lbnQuYm9keS5pbm5lclRleHQgPSBlLnN0YXRlOwogICBpZiAod2luZG93LmxheW91dFRl c3RDb250cm9sbGVyKQogICAgIGxheW91dFRlc3RDb250cm9sbGVyLm5vdGlmeURvbmUoKTsKIH0K IAotb25sb2FkID0gZnVuY3Rpb24oKSB7Ci0gIGlmIChwYXJlbnQgPT0gd2luZG93KSB7Ci0gICAg dmFyIGYgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJpZnJhbWUiKTsKLSAgICBmLnNyYyA9IGxv Y2F0aW9uOwotICAgIGYub25sb2FkID0gZnVuY3Rpb24oKSB7IHNldFRpbWVvdXQocnVuVGVzdCwg MCk7IH07Ci0gICAgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChmKTsKLSAgfQorZnVuY3Rpb24g d2luZG93TG9hZGVkKCkgeworICAvLyBBbGxvdyBsb2FkIHByb2Nlc3NpbmcgdG8gY29tcGxldGUg YmVmb3JlIHdlIHN0YXJ0IG5hdmlnYXRpbmcgYWdhaW4sIHNvCisgIC8vIHRoYXQgbmF2aWdhdGlu ZyB0byBuYXZpZ2F0ZS1iYWNrLmh0bWwgY3JlYXRlcyBhIG5ldyBoaXN0b3J5IGl0ZW0uCisgIHNl dFRpbWVvdXQoZnVuY3Rpb24oKSB7CisgICAgdGVzdFdpbi5mcmFtZXNbMF0uaGlzdG9yeS5yZXBs YWNlU3RhdGUobnVsbCwgbnVsbCk7CisgICAgdGVzdFdpbi5sb2NhdGlvbiA9ICJyZXNvdXJjZXMv bmF2aWdhdGUtYmFjay5odG1sIjsKKyAgfSwgMCk7CiB9CiAKLW9udW5sb2FkID0gZnVuY3Rpb24o KSB7Ci0gIC8vIGRpc2FibGUgcGFnZSBjYWNoZQorb25sb2FkID0gZnVuY3Rpb24oKSB7CisgIHRl c3RXaW4gPSBvcGVuKCJyZXNvdXJjZXMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS13aW5kb3cuaHRt bCIpOworICB0ZXN0V2luLm9ubG9hZCA9IHdpbmRvd0xvYWRlZDsKIH0KIDwvc2NyaXB0PgotPGJv ZHk+ZGVmYXVsdCB0ZXh0PC9ib2R5PgorPGJvZHk+UEVORElORzwvYm9keT4KSW5kZXg6IExheW91 dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXNvdXJjZXMvcmVwbGFjZXN0YXRlLWlu LWlmcmFtZS13aW5kb3ctY2hpbGQuaHRtbA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIExheW91dFRlc3RzL2Zh c3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9yZXNvdXJjZXMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS13 aW5kb3ctY2hpbGQuaHRtbAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2Zhc3QvbG9hZGVy L3N0YXRlb2JqZWN0cy9yZXNvdXJjZXMvcmVwbGFjZXN0YXRlLWluLWlmcmFtZS13aW5kb3ctY2hp bGQuaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxMCBAQAorPHNjcmlwdD4KK29udW5sb2Fk ID0gZnVuY3Rpb24oKSB7CisgIC8vIE5vIHBhZ2UgY2FjaGUKK30KKworb25wb3BzdGF0ZSA9IGZ1 bmN0aW9uKGUpIHsKKyAgYWxlcnQoIm9ucG9wc3RhdGUiKTsKKyAgdG9wLm9wZW5lci5ub3RpZnlE b25lKHdpbmRvdyA9PSBwYXJlbnQgPyAiRkFJTCIgOiAiUEFTUyIpOworfQorPC9zY3JpcHQ+Cklu ZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcmVzb3VyY2VzL3JlcGxh Y2VzdGF0ZS1pbi1pZnJhbWUtd2luZG93Lmh0bWwNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBMYXlvdXRUZXN0 cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcmVzb3VyY2VzL3JlcGxhY2VzdGF0ZS1pbi1pZnJh bWUtd2luZG93Lmh0bWwJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9z dGF0ZW9iamVjdHMvcmVzb3VyY2VzL3JlcGxhY2VzdGF0ZS1pbi1pZnJhbWUtd2luZG93Lmh0bWwJ KHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNiBAQAorPHNjcmlwdD4KK29udW5sb2FkID0gZnVuY3Rp b24oKSB7CisgIC8vIG5vIHBhZ2UgY2FjaGUKK30KKzwvc2NyaXB0PgorPGlmcmFtZSBzcmM9InJl cGxhY2VzdGF0ZS1pbi1pZnJhbWUtd2luZG93LWNoaWxkLmh0bWwiPgo=