38180 2010-04-27 00:55:12 -0700 Remove unneeded custom code for WebSocket.send 2010-06-18 02:31:48 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) Other OS X 10.5 RESOLVED FIXED P2 Normal --- 1 abarth webkit-unassigned ap eric mjs sam ukai oldest_to_newest 217565 0 abarth 2010-04-27 00:55:12 -0700 Remove unneeded custom code for WebSocket.send 217567 1 54393 abarth 2010-04-27 00:56:00 -0700 Created attachment 54393 Patch 217568 2 54393 eric 2010-04-27 00:57:37 -0700 Comment on attachment 54393 Patch Seems like we should write a layout test to explain the badness? 217569 3 abarth 2010-04-27 01:01:55 -0700 It's not really part of our testing plan, but we could. 217757 4 ap 2010-04-27 10:13:42 -0700 - if (exec->hadException()) - return throwError(exec, SyntaxError, "bad message data."); How is this going to be autogenerated? > Seems like we should write a layout test to explain the badness? I'm confused - this bug sounds like it shouldn't change behavior, how can one make a layout test for that? 217767 5 abarth 2010-04-27 10:22:47 -0700 The old code looks wrong. (In reply to comment #4) > - if (exec->hadException()) > - return throwError(exec, SyntaxError, "bad message data."); > > How is this going to be autogenerated? Is that code correct? Why do we do that here but not everywhere else we convert arguments to strings? > > Seems like we should write a layout test to explain the badness? > > I'm confused - this bug sounds like it shouldn't change behavior, how can one > make a layout test for that? - if (args.size() < 1) Why do we check args.size() here? That's very rare in our bindings and usually reserved for when we need it for web compat. Our general philosophy is that args that aren't given are treated as undefined. 217787 6 ap 2010-04-27 10:54:48 -0700 > Is that code correct? Why do we do that here but not everywhere else we > convert arguments to strings? We do that sometimes. In particular, we do that elsewhere in WebSocket bindings code (e.g. constructWebSocket()). > Why do we check args.size() here? That's very rare in our bindings Searching for "if (args.size()" reveals many cases where we check for the number of arguments. I don't have good answers to those questions. It's not unthinkable that most of WebKit code is wrong in this respect. Given that IE and Firefox diverge a lot, and WebIDL is just a working draft, it's hard to even define"right" and "wrong". Providing better error reporting and catching exceptions from argument conversion early both seem to be generally good things to do, although there's of course the question of how these affect performance. 217799 7 abarth 2010-04-27 11:16:31 -0700 (In reply to comment #6) > > Is that code correct? Why do we do that here but not everywhere else we > > convert arguments to strings? > > We do that sometimes. In particular, we do that elsewhere in WebSocket bindings > code (e.g. constructWebSocket()). [...] > Providing better error reporting and catching exceptions from argument > conversion early both seem to be generally good things to do, although there's > of course the question of how these affect performance. If that's the right things to do, then we should do it everywhere. I don't know why we have special-case code here. > > Why do we check args.size() here? That's very rare in our bindings > > Searching for "if (args.size()" reveals many cases where we check for the > number of arguments. Our project-wide policy is not to check args.size() unless we need to. This violates the spec, but my understanding is that we do this to make writing JS wrapper functions easier for library developers. In any case, we should be making these decisions on a project-wide basis (e.g., in the code generator) instead of having randomly different behavior in each location based on who happened to write the custom bindings code. > I don't have good answers to those questions. It's not unthinkable that most of > WebKit code is wrong in this respect. Given that IE and Firefox diverge a lot, > and WebIDL is just a working draft, it's hard to even define"right" and > "wrong". Indeed. However, consistency is a virtue. As far as I can tell, this method is randomly custom for no reason. It seems much better to have it work the same way as every other method. 217802 8 54393 ap 2010-04-27 11:29:36 -0700 Comment on attachment 54393 Patch > It seems much better to have it work the same way as every other method. I don't have a big problem with this change in behavior per se. But I have two problems with this patch: 1. Since it's a behavior change, there should be tests. 2. The "every other method" explanation doesn't really hold water. As I mentioned, there are hundreds of cases where we do the same as the code you are changing does. Those may be a minority, but not a negligible minority. 217987 9 sam 2010-04-27 15:18:43 -0700 (In reply to comment #8) > (From update of attachment 54393 [details]) > > It seems much better to have it work the same way as every other method. > > I don't have a big problem with this change in behavior per se. But I have two > problems with this patch: > 1. Since it's a behavior change, there should be tests. > 2. The "every other method" explanation doesn't really hold water. As I > mentioned, there are hundreds of cases where we do the same as the code you are > changing does. Those may be a minority, but not a negligible minority. I have to agree with Alexey on this one and would add that we should aim to separate cleanup from functionality change. And to reiterate, any functionality change here should be tested. 217992 10 eric 2010-04-27 15:24:31 -0700 Any time we convert a method from custom to autogen a few "bugs" get fixed automatically. One of them is that otherObject.function = Class.proto.function otherObject.function() starts to throw an error because the autogen bindings check to make sure "this" is of the right type, and so far I've not seen a single custom binding do so. If we're going to bother to test such a thing, the test should simply walk the whole tree and test all classes at once. 218028 11 abarth 2010-04-27 16:22:45 -0700 > starts to throw an error because the autogen bindings check to make sure "this" > is of the right type, and so far I've not seen a single custom binding do so. I think that's checked before the custom implementation is called. 218031 12 abarth 2010-04-27 16:26:31 -0700 > I have to agree with Alexey on this one and would add that we should aim to > separate cleanup from functionality change. That's a noble aim, but more or less impossible. The custom bindings are riddled with trivial mistakes. It seems a fools errand to document that we don't have these specific mistakes. There's are infinite sea of trivial mistakes we could have. > And to reiterate, any functionality change here should be tested. In that case, we should accept any new custom bindings code without testing all the trivial behaviors it has since every time we write custom bindings we introduce tons of subtle functionality changes. 218037 13 abarth 2010-04-27 16:35:59 -0700 > In that case, we should accept any new custom bindings code *shouldn't 218043 14 abarth 2010-04-27 16:48:31 -0700 Here's the a diff from the future. Will explain in a minute. --- /tmp/layout-test-results/websocket/tests/send-throw-expected.txt 2010-04-27 16:47:23.000000000 -0700 +++ /tmp/layout-test-results/websocket/tests/send-throw-actual.txt 2010-04-27 16:47:23.000000000 -0700 @@ -3,7 +3,7 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". Connected. -Caught exception: SyntaxError: bad message data. +Caught exception: Pickles Closed. PASS successfullyParsed is true 218049 15 54473 abarth 2010-04-27 16:53:48 -0700 Created attachment 54473 Patch 218050 16 abarth 2010-04-27 16:54:57 -0700 The diff in Comment #14 is the change in behavior from this patch. I think the old behavior is really bogus because it magically catches and mutates the exception. 218059 17 54473 abarth 2010-04-27 17:04:11 -0700 Comment on attachment 54473 Patch There's another difference in behavior, which is whether the side-effects happen when toString throws, which I've filed https://bugs.webkit.org/show_bug.cgi?id=38230 about. 218150 18 ap 2010-04-27 19:19:02 -0700 > https://bugs.webkit.org/show_bug.cgi?id=38230 about For WebSocket specifically, that would be a regression from this patch, right? As mentioned in comment 6, if we're regression this behavior, it makes no sense to do that only for send() - constructWebSocket also has this check. > I think the old behavior is really bogus because it magically catches and > mutates the exception. What do WebIDL or other applicable specs say? 218187 19 sam 2010-04-27 21:08:09 -0700 (In reply to comment #12) > > I have to agree with Alexey on this one and would add that we should aim to > > separate cleanup from functionality change. > > That's a noble aim, but more or less impossible. The custom bindings are > riddled with trivial mistakes. It seems a fools errand to document that we > don't have these specific mistakes. There's are infinite sea of trivial > mistakes we could have. For my benefit, can you list some of them? > > > And to reiterate, any functionality change here should be tested. > > In that case, we should accept any new custom bindings code without testing all > the trivial behaviors it has since every time we write custom bindings we > introduce tons of subtle functionality changes. We expect new code to be well tested, but we need to set a higher bar on changes to existing code since it is a change in existing behavior. For this change in particular, it seems the correct way to go would be to remove the number of arguments check first (with a test as we would require if that was the only thing you wanted to do) and then auto-generate it. 218419 20 abarth 2010-04-28 09:08:33 -0700 (In reply to comment #18) > > https://bugs.webkit.org/show_bug.cgi?id=38230 about > > For WebSocket specifically, that would be a regression from this patch, right? Yes it would. However, the case is quite rare and we have this bug almost everywhere already. I'd be happy to fix it in the code generator so that the fix can be applied to every non-custom binding. > As mentioned in comment 6, if we're regression this behavior, it makes no sense > to do that only for send() - constructWebSocket also has this check. I don't understand this comment. Is there a way to generate constructWebSocket automatically? I haven't looked at it yet. > > I think the old behavior is really bogus because it magically catches and > > mutates the exception. > > What do WebIDL or other applicable specs say? I'm not sure, but if WebIDL says we should mutate the exception, then we have many, many other parts of our bindings that are also out of spec. My point is that autogenerating this code makes it work the same as the vast, vast majority of our bindings. If there are bugs in the autogenerated code, then those bugs exist everywhere and should be fixed. As far as I can tell, there's no reason why this specific API should have custom code that's randomly different than the rest of our code. That's just entropy for the sake of entropy. Autogenerating this code is a step forward even if we randomly respin a bunch of arbitrary subtleties in the API's behavior because we're making those subtleties match how the rest of the bindings work. (In reply to comment #19) > (In reply to comment #12) > > > I have to agree with Alexey on this one and would add that we should aim to > > > separate cleanup from functionality change. > > > > That's a noble aim, but more or less impossible. The custom bindings are > > riddled with trivial mistakes. It seems a fools errand to document that we > > don't have these specific mistakes. There's are infinite sea of trivial > > mistakes we could have. > > For my benefit, can you list some of them? Here's a list off the top of my head: 1) The order in which arguments are coerced to various types can be observed use toString and valueOf. 2) What happens when each of the argument separately (or in combination) throw exceptions: Are the other arguments coerced? Do any side effects happen? Does the exception get swallowed? Which exception do you get thrown? What if the underlying operation generates an exception? 3) Relatedly, if the method operates on objects, when are the identities of those object frozen? For example, if you mutate the DOM or the Frame hierarchy during coercion, do you get the objects from before the mutation or after the mutation? Those are just the ones I can think of related into how and when you coerce arguments. As we remove more custom code, I'm sure we'll find lost more exciting bugs. For example, in NodeIterator, we saw that the custom code was computing DOM wrappers using the wrong global object. The bindings are extremely high-touch regions of code because the web platform can poke at them very directly. Essentially, the only way to ensure uniform behavior is to autogenerate them. The custom bindings we have are a necessary evil in some places, but by and large just filled with trivial (and not so trivial) bugs. > > > And to reiterate, any functionality change here should be tested. > > > > In that case, we should accept any new custom bindings code without testing all > > the trivial behaviors it has since every time we write custom bindings we > > introduce tons of subtle functionality changes. > > We expect new code to be well tested, but we need to set a higher bar on > changes to existing code since it is a change in existing behavior. For this > change in particular, it seems the correct way to go would be to remove the > number of arguments check first (with a test as we would require if that was > the only thing you wanted to do) and then auto-generate it. Well, the patch I posted keeps the argument check using the "RequiresAllArguments" IDL attribute. We can remove that attribute later, if we like. 237383 21 54473 darin 2010-06-12 17:59:49 -0700 Comment on attachment 54473 Patch > + // FIXME: RequiresAllArguments is likely bogus here. I think we should find a better way to keep track of these. I am not sure these “is likely bogus” comments are useful. > + [RequiresAllArguments] boolean send(in DOMString data) > + raises(DOMException); I prefer the "all in one line" style for these. 239810 22 abarth 2010-06-18 01:38:52 -0700 (In reply to comment #21) > (From update of attachment 54473 [details]) > > + // FIXME: RequiresAllArguments is likely bogus here. > > I think we should find a better way to keep track of these. I am not sure these “is likely bogus” comments are useful. Yeah, I removed these comments in the other patches in this vein. > > + [RequiresAllArguments] boolean send(in DOMString data) > > + raises(DOMException); > > I prefer the "all in one line" style for these. Will do. 239830 23 abarth 2010-06-18 02:31:48 -0700 Committed r61390: <http://trac.webkit.org/changeset/61390> 54393 2010-04-27 00:56:00 -0700 2010-04-27 16:53:43 -0700 Patch bug-38180-20100427005558.patch text/plain 3285 abarth ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg ZDk0YWJjNDhhYzJlNWRmMGJkYzQ0MmQ2Mjc5ZjBiNjEyMDI5MThlZC4uM2RjNjkzZGM1MGMyYjk5 ZGQ3ZjQ3ZWJiNzllZjY3ZmI2ZWUwZjEwNCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cK KysrIGIvV2ViQ29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNiBAQAorMjAxMC0wNC0yNyAgQWRh bSBCYXJ0aCAgPGFiYXJ0aEB3ZWJraXQub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9E WSAoT09QUyEpLgorCisgICAgICAgIFJlbW92ZSB1bm5lZWRlZCBjdXN0b20gY29kZSBmb3IgV2Vi U29ja2V0LnNlbmQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTM4MTgwCisKKyAgICAgICAgV2UgZG8gbm90IGFwcGVhciB0byByZXF1aXJlIGN1c3RvbSBi aW5kaW5ncyBoZXJlLgorCisgICAgICAgICogYmluZGluZ3MvanMvSlNXZWJTb2NrZXRDdXN0b20u Y3BwOgorICAgICAgICAqIGJpbmRpbmdzL3Y4L2N1c3RvbS9WOFdlYlNvY2tldEN1c3RvbS5jcHA6 CisgICAgICAgICogd2Vic29ja2V0cy9XZWJTb2NrZXQuaWRsOgorCiAyMDEwLTA0LTI2ICBBZGFt IEJhcnRoICA8YWJhcnRoQHdlYmtpdC5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgRXJpYyBT ZWlkZWwuCmRpZmYgLS1naXQgYS9XZWJDb3JlL2JpbmRpbmdzL2pzL0pTV2ViU29ja2V0Q3VzdG9t LmNwcCBiL1dlYkNvcmUvYmluZGluZ3MvanMvSlNXZWJTb2NrZXRDdXN0b20uY3BwCmluZGV4IDE4 ZjQxODNkYzZhNjQzYjIyNDc3MzM1ZjVlZTliZjAzYzg2NDA1NjYuLjEwMjUxYWUyNjkxMzkyMDY1 ZDI0NzgxY2M4ZDI4MDFlOGI5ODFmZmEgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvYmluZGluZ3MvanMv SlNXZWJTb2NrZXRDdXN0b20uY3BwCisrKyBiL1dlYkNvcmUvYmluZGluZ3MvanMvSlNXZWJTb2Nr ZXRDdXN0b20uY3BwCkBAIC00NCwyMSArNDQsNiBAQCB1c2luZyBuYW1lc3BhY2UgSlNDOwogCiBu YW1lc3BhY2UgV2ViQ29yZSB7CiAKLS8vIEN1c3RvbSBmdW5jdGlvbnMKLUpTVmFsdWUgSlNXZWJT b2NrZXQ6OnNlbmQoRXhlY1N0YXRlKiBleGVjLCBjb25zdCBBcmdMaXN0JiBhcmdzKQotewotICAg IGlmIChhcmdzLnNpemUoKSA8IDEpCi0gICAgICAgIHJldHVybiB0aHJvd0Vycm9yKGV4ZWMsIFN5 bnRheEVycm9yLCAiTm90IGVub3VnaCBhcmd1bWVudHMiKTsKLQotICAgIGNvbnN0IFN0cmluZyYg bXNnID0gdXN0cmluZ1RvU3RyaW5nKGFyZ3MuYXQoMCkudG9TdHJpbmcoZXhlYykpOwotICAgIGlm IChleGVjLT5oYWRFeGNlcHRpb24oKSkKLSAgICAgICAgcmV0dXJuIHRocm93RXJyb3IoZXhlYywg U3ludGF4RXJyb3IsICJiYWQgbWVzc2FnZSBkYXRhLiIpOwotICAgIEV4Y2VwdGlvbkNvZGUgZWMg PSAwOwotICAgIEpTVmFsdWUgcmV0ID0ganNCb29sZWFuKGltcGwoKS0+c2VuZChtc2csIGVjKSk7 Ci0gICAgc2V0RE9NRXhjZXB0aW9uKGV4ZWMsIGVjKTsKLSAgICByZXR1cm4gcmV0OwotfQotCiBK U1ZhbHVlIEpTV2ViU29ja2V0OjphZGRFdmVudExpc3RlbmVyKEV4ZWNTdGF0ZSogZXhlYywgY29u c3QgQXJnTGlzdCYgYXJncykKIHsKICAgICBKU1ZhbHVlIGxpc3RlbmVyID0gYXJncy5hdCgxKTsK ZGlmZiAtLWdpdCBhL1dlYkNvcmUvYmluZGluZ3MvdjgvY3VzdG9tL1Y4V2ViU29ja2V0Q3VzdG9t LmNwcCBiL1dlYkNvcmUvYmluZGluZ3MvdjgvY3VzdG9tL1Y4V2ViU29ja2V0Q3VzdG9tLmNwcApp bmRleCBiOTMxMDUzOGQxN2NkMzMzOWI2NWI5YTgwMDY3MWRhOWViZWNjNWFlLi41ZTE1ZGFiODlh YzRhNjA4MjBhZWQ2MTE3ZDE1NWUzZjUxMzY5NzVkIDEwMDY0NAotLS0gYS9XZWJDb3JlL2JpbmRp bmdzL3Y4L2N1c3RvbS9WOFdlYlNvY2tldEN1c3RvbS5jcHAKKysrIGIvV2ViQ29yZS9iaW5kaW5n cy92OC9jdXN0b20vVjhXZWJTb2NrZXRDdXN0b20uY3BwCkBAIC05MywyNCArOTMsNiBAQCB2ODo6 SGFuZGxlPHY4OjpWYWx1ZT4gVjhXZWJTb2NrZXQ6OmNvbnN0cnVjdG9yQ2FsbGJhY2soY29uc3Qg djg6OkFyZ3VtZW50cyYgYXJncwogICAgIHJldHVybiBhcmdzLkhvbGRlcigpOwogfQogCi12ODo6 SGFuZGxlPHY4OjpWYWx1ZT4gVjhXZWJTb2NrZXQ6OnNlbmRDYWxsYmFjayhjb25zdCB2ODo6QXJn dW1lbnRzJiBhcmdzKQotewotICAgIElOQ19TVEFUUygiRE9NLldlYlNvY2tldC5zZW5kKCkiKTsK LSAgICBXZWJTb2NrZXQqIHdlYlNvY2tldCA9IFY4V2ViU29ja2V0Ojp0b05hdGl2ZShhcmdzLkhv bGRlcigpKTsKLQotICAgIEV4Y2VwdGlvbkNvZGUgZWMgPSAwOwotICAgIGJvb2wgcmV0ID0gZmFs c2U7Ci0gICAgaWYgKGFyZ3MuTGVuZ3RoKCkgPCAxKQotICAgICAgICByZXR1cm4gdGhyb3dFcnJv cigiTm90IGVub3VnaCBhcmd1bWVudHMiLCBWOFByb3h5OjpTeW50YXhFcnJvcik7Ci0gICAgZWxz ZSB7Ci0gICAgICAgIFN0cmluZyBtc2cgPSB0b1dlYkNvcmVTdHJpbmcoYXJnc1swXSk7Ci0gICAg ICAgIHJldCA9IHdlYlNvY2tldC0+c2VuZChtc2csIGVjKTsKLSAgICB9Ci0gICAgaWYgKGVjKQot ICAgICAgICByZXR1cm4gdGhyb3dFcnJvcihlYyk7Ci0gICAgcmV0dXJuIHY4Qm9vbGVhbihyZXQp OwotfQotCiB9ICAvLyBuYW1lc3BhY2UgV2ViQ29yZQogCiAjZW5kaWYgIC8vIEVOQUJMRShXRUJf U09DS0VUUykKZGlmZiAtLWdpdCBhL1dlYkNvcmUvd2Vic29ja2V0cy9XZWJTb2NrZXQuaWRsIGIv V2ViQ29yZS93ZWJzb2NrZXRzL1dlYlNvY2tldC5pZGwKaW5kZXggMTcwNzQ3OGUyNWM4MDUxOTMy MTViZTJmMmZjM2YzNjYwZGYzOTIyYi4uNTY3ODE1YWY5YTg1YTg3M2NiZjRjNTkwMDg2NzEwMDJj YjYwNmMwMCAxMDA2NDQKLS0tIGEvV2ViQ29yZS93ZWJzb2NrZXRzL1dlYlNvY2tldC5pZGwKKysr IGIvV2ViQ29yZS93ZWJzb2NrZXRzL1dlYlNvY2tldC5pZGwKQEAgLTUyLDggKzUyLDggQEAgbW9k dWxlIHdlYnNvY2tldHMgewogICAgICAgICBhdHRyaWJ1dGUgRXZlbnRMaXN0ZW5lciBvbmVycm9y OwogICAgICAgICBhdHRyaWJ1dGUgRXZlbnRMaXN0ZW5lciBvbmNsb3NlOwogCi0gICAgICAgIFtD dXN0b21dIGJvb2xlYW4gc2VuZChpbiBET01TdHJpbmcgZGF0YSkKLSAgICAgICAgICByYWlzZXMo RE9NRXhjZXB0aW9uKTsKKyAgICAgICAgYm9vbGVhbiBzZW5kKGluIERPTVN0cmluZyBkYXRhKQor ICAgICAgICAgICAgcmFpc2VzKERPTUV4Y2VwdGlvbik7CiAgICAgICAgIHZvaWQgY2xvc2UoKTsK IAogICAgICAgICAvLyBFdmVudFRhcmdldCBpbnRlcmZhY2UK 54473 2010-04-27 16:53:48 -0700 2010-06-12 17:59:49 -0700 Patch bug-38180-20100427165346.patch text/plain 7213 abarth ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBmNGZiMGQwNGU5MWIyNDdjZWE5NGVkYzBjMjljMzE4Njg2MGE0ODA3Li4yZjEyMDBj ZGU0YjAxNzM5MTRjZThkZTBmNjYxNDJkMDE2NWE3YzQyIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0 cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjIgQEAK KzIwMTAtMDQtMjcgIEFkYW0gQmFydGggIDxhYmFydGhAd2Via2l0Lm9yZz4KKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSZW1vdmUgdW5uZWVkZWQgY3Vz dG9tIGNvZGUgZm9yIFdlYlNvY2tldC5zZW5kCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0zODE4MAorCisgICAgICAgIFRlc3Qgd2hhdCBoYXBwZW5zIHdo ZW4geW91IHBhc3MgYW4gb2JqZWN0IHRvIFdlYlNvY2tldC5zZW5kIHRoYXQgdGhyb3dzCisgICAg ICAgIHdoZW4geW91IGNvbnZlcnQgaXQgdG8gYSBzdHJpbmcuCisKKyAgICAgICAgKiB3ZWJzb2Nr ZXQvdGVzdHMvc2NyaXB0LXRlc3RzL3NlbmQtdGhyb3cuanM6IEFkZGVkLgorICAgICAgICAoZW5k VGVzdCk6CisgICAgICAgIChGSVJTVF9NRVNTQUdFX1RPX1NFTkQudG9TdHJpbmcpOgorICAgICAg ICAod3Mub25vcGVuKToKKyAgICAgICAgKHdzLm9uY2xvc2UpOgorICAgICAgICAodGltZU91dENh bGxiYWNrKToKKyAgICAgICAgKiB3ZWJzb2NrZXQvdGVzdHMvc2VuZC10aHJvdy1leHBlY3RlZC50 eHQ6IEFkZGVkLgorICAgICAgICAqIHdlYnNvY2tldC90ZXN0cy9zZW5kLXRocm93Lmh0bWw6IEFk ZGVkLgorCiAyMDEwLTA0LTI3ICBGcmFuw6dvaXMgU2F1c3NldCAgPHNhdXNzZXRAZ21haWwuY29t PgogCiAgICAgICAgIFJldmlld2VkIGJ5IEtlbm5ldGggUm9oZGUgQ2hyaXN0aWFuc2VuLgpkaWZm IC0tZ2l0IGEvTGF5b3V0VGVzdHMvd2Vic29ja2V0L3Rlc3RzL3NjcmlwdC10ZXN0cy9zZW5kLXRo cm93LmpzIGIvTGF5b3V0VGVzdHMvd2Vic29ja2V0L3Rlc3RzL3NjcmlwdC10ZXN0cy9zZW5kLXRo cm93LmpzCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAuLjkyYTljYzhkM2NhOTc0ZjdmODVlNmVkYTQ4ZTk3MDhlNjdkNTY0 YmMKLS0tIC9kZXYvbnVsbAorKysgYi9MYXlvdXRUZXN0cy93ZWJzb2NrZXQvdGVzdHMvc2NyaXB0 LXRlc3RzL3NlbmQtdGhyb3cuanMKQEAgLTAsMCArMSw0NyBAQAorZGVzY3JpcHRpb24oIldlYiBT b2NrZXQgc2VuZCB0ZXN0Iik7CisKK2lmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCisg ICAgbGF5b3V0VGVzdENvbnRyb2xsZXIud2FpdFVudGlsRG9uZSgpOworCitmdW5jdGlvbiBlbmRU ZXN0KCkKK3sKKyAgICBpc1N1Y2Nlc3NmdWxseVBhcnNlZCgpOworICAgIGNsZWFyVGltZW91dCh0 aW1lb3V0SUQpOworICAgIGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCisgICAgICAg IGxheW91dFRlc3RDb250cm9sbGVyLm5vdGlmeURvbmUoKTsKK30KKwordmFyIHdzID0gbmV3IFdl YlNvY2tldCgid3M6Ly9sb2NhbGhvc3Q6ODg4MC93ZWJzb2NrZXQvdGVzdHMvc2VuZCIpOworCit2 YXIgRklSU1RfTUVTU0FHRV9UT19TRU5EID0geworICAgIHRvU3RyaW5nOiBmdW5jdGlvbigpIHsg dGhyb3cgIlBpY2tsZXMiOyB9Cit9OworLy8gZGF0YSBuZWVkcyB0byBiZSBnbG9iYWwgdG8gYmUg YWNjZXNzYmlsZSBmcm9tIHNob3VsZEJlKCkuCit2YXIgZGF0YSA9ICIiOworCit3cy5vbm9wZW4g PSBmdW5jdGlvbigpCit7CisgICAgZGVidWcoIkNvbm5lY3RlZC4iKTsKKyAgICB0cnkgeworICAg ICAgICB3cy5zZW5kKEZJUlNUX01FU1NBR0VfVE9fU0VORCk7CisgICAgfSBjYXRjaCAoZXgpIHsK KyAgICAgICAgZGVidWcoIkNhdWdodCBleGNlcHRpb246ICIgKyBleCk7CisgICAgfQorICAgIHdz LmNsb3NlKCk7Cit9OworCit3cy5vbmNsb3NlID0gZnVuY3Rpb24oKQoreworICAgIGRlYnVnKCJD bG9zZWQuIik7CisgICAgZW5kVGVzdCgpOworfTsKKworZnVuY3Rpb24gdGltZU91dENhbGxiYWNr KCkKK3sKKyAgICB0ZXN0RmFpbGVkKCJUaW1lZCBvdXQgaW4gc3RhdGU6ICIgKyB3cy5yZWFkeVN0 YXRlKTsKKyAgICBlbmRUZXN0KCk7Cit9CisKK3ZhciB0aW1lb3V0SUQgPSBzZXRUaW1lb3V0KHRp bWVPdXRDYWxsYmFjaywgMzAwMCk7CisKK3ZhciBzdWNjZXNzZnVsbHlQYXJzZWQgPSB0cnVlOwpk aWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvd2Vic29ja2V0L3Rlc3RzL3NlbmQtdGhyb3ctZXhwZWN0 ZWQudHh0IGIvTGF5b3V0VGVzdHMvd2Vic29ja2V0L3Rlc3RzL3NlbmQtdGhyb3ctZXhwZWN0ZWQu dHh0Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAuLmFhNzRiYTMxNTQxNWZjMGQyZjRlNmQ1MDYyMjYyMzVjMDFmYmIyNmEK LS0tIC9kZXYvbnVsbAorKysgYi9MYXlvdXRUZXN0cy93ZWJzb2NrZXQvdGVzdHMvc2VuZC10aHJv dy1leHBlY3RlZC50eHQKQEAgLTAsMCArMSwxMSBAQAorV2ViIFNvY2tldCBzZW5kIHRlc3QKKwor T24gc3VjY2VzcywgeW91IHdpbGwgc2VlIGEgc2VyaWVzIG9mICJQQVNTIiBtZXNzYWdlcywgZm9s bG93ZWQgYnkgIlRFU1QgQ09NUExFVEUiLgorCitDb25uZWN0ZWQuCitDYXVnaHQgZXhjZXB0aW9u OiBQaWNrbGVzCitDbG9zZWQuCitQQVNTIHN1Y2Nlc3NmdWxseVBhcnNlZCBpcyB0cnVlCisKK1RF U1QgQ09NUExFVEUKKwpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvd2Vic29ja2V0L3Rlc3RzL3Nl bmQtdGhyb3cuaHRtbCBiL0xheW91dFRlc3RzL3dlYnNvY2tldC90ZXN0cy9zZW5kLXRocm93Lmh0 bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMC4uNzUwYmEyMDM1NGUxNjk0M2Y5ODcyMzczMTA1NzU2YzM0YjA5MWJjMQot LS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL3dlYnNvY2tldC90ZXN0cy9zZW5kLXRocm93 Lmh0bWwKQEAgLTAsMCArMSwxMyBAQAorPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9JRVRGLy9E VEQgSFRNTC8vRU4iPgorPGh0bWw+Cis8aGVhZD4KKzxsaW5rIHJlbD0ic3R5bGVzaGVldCIgaHJl Zj0iLi4vLi4vZmFzdC9qcy9yZXNvdXJjZXMvanMtdGVzdC1zdHlsZS5jc3MiPgorPHNjcmlwdCBz cmM9Ii4uLy4uL2Zhc3QvanMvcmVzb3VyY2VzL2pzLXRlc3QtcHJlLmpzIj48L3NjcmlwdD4KKzxz Y3JpcHQgc3JjPSIuLi8uLi9mYXN0L2pzL3Jlc291cmNlcy9qcy10ZXN0LXBvc3QtZnVuY3Rpb24u anMiPjwvc2NyaXB0PgorPC9oZWFkPgorPGJvZHk+Cis8ZGl2IGlkPSJkZXNjcmlwdGlvbiI+PC9k aXY+Cis8ZGl2IGlkPSJjb25zb2xlIj48L2Rpdj4KKzxzY3JpcHQgc3JjPSJzY3JpcHQtdGVzdHMv c2VuZC10aHJvdy5qcyI+PC9zY3JpcHQ+Cis8L2JvZHk+Cis8L2h0bWw+CmRpZmYgLS1naXQgYS9X ZWJDb3JlL0NoYW5nZUxvZyBiL1dlYkNvcmUvQ2hhbmdlTG9nCmluZGV4IGQ3MTlhNTBhOTU2YmVj NTdiYTI4ZTIxMzE1MWY1Yzg0NjVkMWYwYzYuLjNmZjk0NDExMGViNTBjMjMzMDRkYzczN2NkZmQ3 MjEyZmI0NmVjMDcgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1dlYkNvcmUv Q2hhbmdlTG9nCkBAIC0xLDMgKzEsMjcgQEAKKzIwMTAtMDQtMjcgIEFkYW0gQmFydGggIDxhYmFy dGhAd2Via2l0Lm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKwor ICAgICAgICBSZW1vdmUgdW5uZWVkZWQgY3VzdG9tIGNvZGUgZm9yIFdlYlNvY2tldC5zZW5kCisg ICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zODE4MAorCisg ICAgICAgIFdlIGRvbid0IGFwcGVhciB0byByZXF1aXJlIGEgY3VzdG9tIGJpbmRpbmcgaGVyZS4g IFRoZSBvbGQgZnVuY3Rpb24gd2FzCisgICAgICAgIHdhY2t5IGluIHR3byB3YXlzOgorCisgICAg ICAgIDEpIEl0IHJlcXVpcmVkIGFsbCBvZiBpdHMgYXJndW1lbnRzLgorCisgICAgICAgIDIpIElm IHRoZSB0b1N0cmluZyBvZiBpdHMgYXJndW1lbnQgdGhyZXcsIGl0IHdvdWxkIGNhdGNoIHRoZSBl eGNlcHRpb24KKyAgICAgICAgICAgYW5kIHJlLXRocm93IGEgZGlmZmVyZW50IGV4Y2VwdGlvbi4K KworICAgICAgICBJJ3ZlIGtlcHQgdGhlIGZpcnN0IGJlaGF2aW9yIGJ1dCBjaGFuZ2VkIHRoZSBz ZWNvbmQgKGFuZCBkb2N1bWVudGVkIGl0CisgICAgICAgIHdpdGggYSB0ZXN0KS4KKworICAgICAg ICBUZXN0OiB3ZWJzb2NrZXQvdGVzdHMvc2VuZC10aHJvdy5odG1sCisKKyAgICAgICAgKiBiaW5k aW5ncy9qcy9KU1dlYlNvY2tldEN1c3RvbS5jcHA6CisgICAgICAgICogYmluZGluZ3MvdjgvY3Vz dG9tL1Y4V2ViU29ja2V0Q3VzdG9tLmNwcDoKKyAgICAgICAgKiB3ZWJzb2NrZXRzL1dlYlNvY2tl dC5pZGw6CisKIDIwMTAtMDQtMjcgIEtpbnVrbyBZYXN1ZGEgIDxraW51a29AY2hyb21pdW0ub3Jn PgogCiAgICAgICAgIFJldmlld2VkIGJ5IEppYW4gTGkuCmRpZmYgLS1naXQgYS9XZWJDb3JlL2Jp bmRpbmdzL2pzL0pTV2ViU29ja2V0Q3VzdG9tLmNwcCBiL1dlYkNvcmUvYmluZGluZ3MvanMvSlNX ZWJTb2NrZXRDdXN0b20uY3BwCmluZGV4IDE0OWFjNWQwN2YzMzE1MDczOTI0M2JjZTVhZDNiNTUw ODZhNTg1NmMuLjFmYThlYjZlNmU1MTVkOTFkM2YxYzcyMWI1YTFiYjk5YmE5NmU3MTggMTAwNjQ0 Ci0tLSBhL1dlYkNvcmUvYmluZGluZ3MvanMvSlNXZWJTb2NrZXRDdXN0b20uY3BwCisrKyBiL1dl YkNvcmUvYmluZGluZ3MvanMvSlNXZWJTb2NrZXRDdXN0b20uY3BwCkBAIC00NCwyMCArNDQsNyBA QCB1c2luZyBuYW1lc3BhY2UgSlNDOwogCiBuYW1lc3BhY2UgV2ViQ29yZSB7CiAKLS8vIEN1c3Rv bSBmdW5jdGlvbnMKLUpTVmFsdWUgSlNXZWJTb2NrZXQ6OnNlbmQoRXhlY1N0YXRlKiBleGVjLCBj b25zdCBBcmdMaXN0JiBhcmdzKQotewotICAgIGlmIChhcmdzLnNpemUoKSA8IDEpCi0gICAgICAg IHJldHVybiB0aHJvd0Vycm9yKGV4ZWMsIFN5bnRheEVycm9yLCAiTm90IGVub3VnaCBhcmd1bWVu dHMiKTsKLQotICAgIGNvbnN0IFN0cmluZyYgbXNnID0gdXN0cmluZ1RvU3RyaW5nKGFyZ3MuYXQo MCkudG9TdHJpbmcoZXhlYykpOwotICAgIGlmIChleGVjLT5oYWRFeGNlcHRpb24oKSkKLSAgICAg ICAgcmV0dXJuIHRocm93RXJyb3IoZXhlYywgU3ludGF4RXJyb3IsICJiYWQgbWVzc2FnZSBkYXRh LiIpOwotICAgIEV4Y2VwdGlvbkNvZGUgZWMgPSAwOwotICAgIEpTVmFsdWUgcmV0ID0ganNCb29s ZWFuKGltcGwoKS0+c2VuZChtc2csIGVjKSk7Ci0gICAgc2V0RE9NRXhjZXB0aW9uKGV4ZWMsIGVj KTsKLSAgICByZXR1cm4gcmV0OwotfQorLy8gRklYTUU6IFJlbW92ZSB0aGlzIGZpbGUuCiAKIH0g IC8vIG5hbWVzcGFjZSBXZWJDb3JlCiAKZGlmZiAtLWdpdCBhL1dlYkNvcmUvYmluZGluZ3Mvdjgv Y3VzdG9tL1Y4V2ViU29ja2V0Q3VzdG9tLmNwcCBiL1dlYkNvcmUvYmluZGluZ3MvdjgvY3VzdG9t L1Y4V2ViU29ja2V0Q3VzdG9tLmNwcAppbmRleCBiOTMxMDUzOGQxN2NkMzMzOWI2NWI5YTgwMDY3 MWRhOWViZWNjNWFlLi41ZTE1ZGFiODlhYzRhNjA4MjBhZWQ2MTE3ZDE1NWUzZjUxMzY5NzVkIDEw MDY0NAotLS0gYS9XZWJDb3JlL2JpbmRpbmdzL3Y4L2N1c3RvbS9WOFdlYlNvY2tldEN1c3RvbS5j cHAKKysrIGIvV2ViQ29yZS9iaW5kaW5ncy92OC9jdXN0b20vVjhXZWJTb2NrZXRDdXN0b20uY3Bw CkBAIC05MywyNCArOTMsNiBAQCB2ODo6SGFuZGxlPHY4OjpWYWx1ZT4gVjhXZWJTb2NrZXQ6OmNv bnN0cnVjdG9yQ2FsbGJhY2soY29uc3Qgdjg6OkFyZ3VtZW50cyYgYXJncwogICAgIHJldHVybiBh cmdzLkhvbGRlcigpOwogfQogCi12ODo6SGFuZGxlPHY4OjpWYWx1ZT4gVjhXZWJTb2NrZXQ6OnNl bmRDYWxsYmFjayhjb25zdCB2ODo6QXJndW1lbnRzJiBhcmdzKQotewotICAgIElOQ19TVEFUUygi RE9NLldlYlNvY2tldC5zZW5kKCkiKTsKLSAgICBXZWJTb2NrZXQqIHdlYlNvY2tldCA9IFY4V2Vi U29ja2V0Ojp0b05hdGl2ZShhcmdzLkhvbGRlcigpKTsKLQotICAgIEV4Y2VwdGlvbkNvZGUgZWMg PSAwOwotICAgIGJvb2wgcmV0ID0gZmFsc2U7Ci0gICAgaWYgKGFyZ3MuTGVuZ3RoKCkgPCAxKQot ICAgICAgICByZXR1cm4gdGhyb3dFcnJvcigiTm90IGVub3VnaCBhcmd1bWVudHMiLCBWOFByb3h5 OjpTeW50YXhFcnJvcik7Ci0gICAgZWxzZSB7Ci0gICAgICAgIFN0cmluZyBtc2cgPSB0b1dlYkNv cmVTdHJpbmcoYXJnc1swXSk7Ci0gICAgICAgIHJldCA9IHdlYlNvY2tldC0+c2VuZChtc2csIGVj KTsKLSAgICB9Ci0gICAgaWYgKGVjKQotICAgICAgICByZXR1cm4gdGhyb3dFcnJvcihlYyk7Ci0g ICAgcmV0dXJuIHY4Qm9vbGVhbihyZXQpOwotfQotCiB9ICAvLyBuYW1lc3BhY2UgV2ViQ29yZQog CiAjZW5kaWYgIC8vIEVOQUJMRShXRUJfU09DS0VUUykKZGlmZiAtLWdpdCBhL1dlYkNvcmUvd2Vi c29ja2V0cy9XZWJTb2NrZXQuaWRsIGIvV2ViQ29yZS93ZWJzb2NrZXRzL1dlYlNvY2tldC5pZGwK aW5kZXggY2M0YTA3YjZjOGEzYjgyMmRlMmU5ODYzYWExMjU3ODhmYmMwYzlkMy4uNjhhOGFiZWM0 MGE0YTRlNTJmNmI5YTM5MmUwMjNkMzliMjVmNTA4OSAxMDA2NDQKLS0tIGEvV2ViQ29yZS93ZWJz b2NrZXRzL1dlYlNvY2tldC5pZGwKKysrIGIvV2ViQ29yZS93ZWJzb2NrZXRzL1dlYlNvY2tldC5p ZGwKQEAgLTUyLDggKzUyLDkgQEAgbW9kdWxlIHdlYnNvY2tldHMgewogICAgICAgICBhdHRyaWJ1 dGUgRXZlbnRMaXN0ZW5lciBvbmVycm9yOwogICAgICAgICBhdHRyaWJ1dGUgRXZlbnRMaXN0ZW5l ciBvbmNsb3NlOwogCi0gICAgICAgIFtDdXN0b21dIGJvb2xlYW4gc2VuZChpbiBET01TdHJpbmcg ZGF0YSkKLSAgICAgICAgICByYWlzZXMoRE9NRXhjZXB0aW9uKTsKKyAgICAgICAgLy8gRklYTUU6 IFJlcXVpcmVzQWxsQXJndW1lbnRzIGlzIGxpa2VseSBib2d1cyBoZXJlLgorICAgICAgICBbUmVx dWlyZXNBbGxBcmd1bWVudHNdIGJvb2xlYW4gc2VuZChpbiBET01TdHJpbmcgZGF0YSkKKyAgICAg ICAgICAgIHJhaXNlcyhET01FeGNlcHRpb24pOwogICAgICAgICB2b2lkIGNsb3NlKCk7CiAKICAg ICAgICAgLy8gRXZlbnRUYXJnZXQgaW50ZXJmYWNlCg==