193420 2019-01-14 17:13:37 -0800 JSScript API should only take ascii files. 2019-01-22 10:42:04 -0800 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 keith_miller keith_miller ap commit-queue ews-watchlist mark.lam msaboff saam webkit-bug-importer oldest_to_newest 1494412 0 keith_miller 2019-01-14 17:13:37 -0800 JSScript API should only take ascii files. 1494414 1 359101 keith_miller 2019-01-14 17:14:03 -0800 Created attachment 359101 Patch 1494446 2 359101 ap 2019-01-14 18:22:52 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review > Source/JavaScriptCore/ChangeLog:3 > + JSScript API should only take ascii files. Why? ASCII is not cool. 1494458 3 359101 keith_miller 2019-01-14 18:42:36 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review >> Source/JavaScriptCore/ChangeLog:3 >> + JSScript API should only take ascii files. > > Why? ASCII is not cool. It's that or UTF16... WTF doesn't support UTF-8 strings. I guess it could be Latin1? 1494481 4 ap 2019-01-14 19:28:53 -0800 > WTF doesn't support UTF-8 strings. Which part of WTF doesn't? The code was already using String::fromUTF8WithLatin1Fallback... I would say that we don't want latin-1 fallback in an API, but other than that, not sure what the issue is. 1494682 5 keith_miller 2019-01-15 10:11:58 -0800 (In reply to Alexey Proskuryakov from comment #4) > > WTF doesn't support UTF-8 strings. > > Which part of WTF doesn't? The code was already using > String::fromUTF8WithLatin1Fallback... I would say that we don't want latin-1 > fallback in an API, but other than that, not sure what the issue is. Sorry, I mean without modifying the source data. This API is intended to mmap a file so the source doesn't count against dirty memory. (which it doesn't do yet). StringImpls are either latin1 or UTF-16, AFAIK. 1494723 6 ap 2019-01-15 11:01:54 -0800 I see. It seems not great to shape an API based on current low level implementation details. I would suggest making the API universal, and if it has an optimized path that certain clients can opt into, good for those clients. As you already iterate over all the characters in the source, you could keep it as scriptFromUTF8File, and use mmapped buffer if the check passes. Alternatively, why not make mmapping client's responsibility? There is enough to worry about that JavaScriptCore is not prepared for in general, such as concurrent writing to the file, or unmounting the file system. JSC can't make a file based API work predictably in those cases, so it seems better leaving to the client to decide what to do there, or to guarantee that they don't care. 1494741 7 saam 2019-01-15 11:51:08 -0800 Why can't we just have a constructor called JSASCIIScript or something similar so the name dictates this property? 1494742 8 359101 saam 2019-01-15 11:52:24 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review > Source/JavaScriptCore/API/JSScript.mm:98 > + for (char c : buffer) { > + if (!isASCII(c)) > + return nil; > + } Do we really want to pull the entire file into memory? Why can't we just debug assert this? If we move to properly naming this something like JSASCIIScript... 1494745 9 359101 keith_miller 2019-01-15 11:56:16 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review >> Source/JavaScriptCore/API/JSScript.mm:98 >> + } > > Do we really want to pull the entire file into memory? Why can't we just debug assert this? If we move to properly naming this something like JSASCIIScript... Are you saying that we should rename the class or this constructor? I'm not sure that we only ever want to support ASCII scripts. We could also have a scriptFromUTF16 SPI constructor in the future. As far as pulling the whole file into memory. There is a FIXME to mmap the contents of the file so it shouldn't count against us. Also, we are going to call a code signing function that is going to hash the entire file for signing anyway. 1494756 10 359101 saam 2019-01-15 12:26:10 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review >>> Source/JavaScriptCore/API/JSScript.mm:98 >>> + } >> >> Do we really want to pull the entire file into memory? Why can't we just debug assert this? If we move to properly naming this something like JSASCIIScript... > > Are you saying that we should rename the class or this constructor? I'm not sure that we only ever want to support ASCII scripts. We could also have a scriptFromUTF16 SPI constructor in the future. > > As far as pulling the whole file into memory. There is a FIXME to mmap the contents of the file so it shouldn't count against us. Also, we are going to call a code signing function that is going to hash the entire file for signing anyway. Good point regarding pulling in all memory. I think having the name just in this constructor function is fine. 1494852 11 359101 ap 2019-01-15 15:16:52 -0800 Comment on attachment 359101 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=359101&action=review > Source/JavaScriptCore/API/JSScript.h:58 > ++ (nullable instancetype)scriptFromASCIIFile:(NSURL *)filePath inVirtualMachine:(JSVirtualMachine *)vm withCodeSigning:(nullable NSURL *)codeSigningPath andBytecodeCache:(nullable NSURL *)cachePath; Still looks really bad to me as an API, Saam's r+ notwithstanding. 1496145 12 359574 keith_miller 2019-01-18 18:57:56 -0800 Created attachment 359574 Patch for landing 1496165 13 359574 commit-queue 2019-01-18 19:35:50 -0800 Comment on attachment 359574 Patch for landing Clearing flags on attachment: 359574 Committed r240194: <https://trac.webkit.org/changeset/240194> 1496166 14 commit-queue 2019-01-18 19:35:51 -0800 All reviewed patches have been landed. Closing bug. 1496167 15 webkit-bug-importer 2019-01-18 19:36:29 -0800 <rdar://problem/47404335> 1496341 16 saam 2019-01-20 12:24:24 -0800 (In reply to Alexey Proskuryakov from comment #11) > Comment on attachment 359101 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=359101&action=review > > > Source/JavaScriptCore/API/JSScript.h:58 > > ++ (nullable instancetype)scriptFromASCIIFile:(NSURL *)filePath inVirtualMachine:(JSVirtualMachine *)vm withCodeSigning:(nullable NSURL *)codeSigningPath andBytecodeCache:(nullable NSURL *)cachePath; > > Still looks really bad to me as an API, Saam's r+ notwithstanding. Can you propose an alternative SPI? 1496393 17 keith_miller 2019-01-20 14:17:25 -0800 (In reply to Saam Barati from comment #16) > (In reply to Alexey Proskuryakov from comment #11) > > Comment on attachment 359101 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=359101&action=review > > > > > Source/JavaScriptCore/API/JSScript.h:58 > > > ++ (nullable instancetype)scriptFromASCIIFile:(NSURL *)filePath inVirtualMachine:(JSVirtualMachine *)vm withCodeSigning:(nullable NSURL *)codeSigningPath andBytecodeCache:(nullable NSURL *)cachePath; > > > > Still looks really bad to me as an API, Saam's r+ notwithstanding. > > Can you propose an alternative SPI? This SPI was decided upon because we were asked to manage the bytecode cache. Since, we need to read and write files for that part of the SPI it seems reasonable that the whole SPI would handle files, IMO. 1496461 18 ap 2019-01-20 18:04:19 -0800 > Can you propose an alternative SPI? I did already. First of all, scriptFromUTF8File was perfectly fine as API, as you could choose to use a memory mapped buffer after checking the content. Secondly, I recommend against dealing with files, especially for something long lived like mmap. The client that you have in mind today may not care, but future clients may have expectations with regards to wasting open file handles, or to how the process responds to file system unmounting or flakiness. The documentation doesn't even call it out that there will be side effects beyond creating the script. > This SPI was decided upon because we were asked to manage the bytecode cache. Since, we need to read and write files for that part of the SPI it seems reasonable that the whole SPI would handle files, IMO. For the cache, you can have reasonable expectations for file system staying in place, as well as whether files will be deleted underneath you. 1496469 19 saam 2019-01-20 18:49:49 -0800 (In reply to Alexey Proskuryakov from comment #18) > > Can you propose an alternative SPI? > > I did already. > > First of all, scriptFromUTF8File was perfectly fine as API, as you could > choose to use a memory mapped buffer after checking the content. Since this is SPI, I think it makes sense for the SPI to fail instead of silently opt you into using more memory than you expected. When using a lower level SPI like this, we want clients to know when they mess up and opt themselves back into using more memory than they wanted to. The whole point of using this SPI is to use less memory. It feels weird doing something that might cost the client memory when they were not expecting it. > > Secondly, I recommend against dealing with files, especially for something > long lived like mmap. The client that you have in mind today may not care, > but future clients may have expectations with regards to wasting open file > handles, or to how the process responds to file system unmounting or > flakiness. The documentation doesn't even call it out that there will be > side effects beyond creating the script. > > > This SPI was decided upon because we were asked to manage the bytecode cache. Since, we need to read and write files for that part of the SPI it seems reasonable that the whole SPI would handle files, IMO. > > For the cache, you can have reasonable expectations for file system staying > in place, as well as whether files will be deleted underneath you. 1496470 20 saam 2019-01-20 18:53:47 -0800 (In reply to Alexey Proskuryakov from comment #18) > > Can you propose an alternative SPI? > > I did already. I see. Sorry I missed that comment... > > First of all, scriptFromUTF8File was perfectly fine as API, as you could > choose to use a memory mapped buffer after checking the content. > > Secondly, I recommend against dealing with files, especially for something > long lived like mmap. The client that you have in mind today may not care, > but future clients may have expectations with regards to wasting open file > handles, or to how the process responds to file system unmounting or > flakiness. The documentation doesn't even call it out that there will be > side effects beyond creating the script. > > > This SPI was decided upon because we were asked to manage the bytecode cache. Since, we need to read and write files for that part of the SPI it seems reasonable that the whole SPI would handle files, IMO. > > For the cache, you can have reasonable expectations for file system staying > in place, as well as whether files will be deleted underneath you. 1496472 21 saam 2019-01-20 18:55:28 -0800 (In reply to Alexey Proskuryakov from comment #6) > Alternatively, why not make mmapping client's responsibility? There is > enough to worry about that JavaScriptCore is not prepared for in general, > such as concurrent writing to the file, or unmounting the file system. JSC > can't make a file based API work predictably in those cases, so it seems > better leaving to the client to decide what to do there, or to guarantee > that they don't care. I mostly agree with this. I think it'd be nicer if it were the client's responsibility. The only thing that gives me some pause is if we recommend this to N different clients, and they implement it N different ways, perhaps we should implement it ourselves. But maybe that's a bridge we should cross when we get there. 1496822 22 ap 2019-01-22 10:42:04 -0800 > The whole point of using this SPI is to use less memory. I see. Not sure how huge the files in question are. In any case, it seems like setting up a memory use test would be a better long term way to make sure that memory use doesn't grow. There are certainly many things we can do that increase memory use, and having an SPI guarantee that there is no copy at the very edge doesn't do very much to defend the memory use goal. 359101 2019-01-14 17:14:03 -0800 2019-01-18 18:57:54 -0800 Patch bug-193420-20190114171401.patch text/plain 4387 keith_miller U3VidmVyc2lvbiBSZXZpc2lvbjogMjM5OTMzCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBk MGE1ODMyNzRiMGQ4ZjE5NzllNDMzOTAxYTRlZWIwMDIxZDQ5OTY3Li42OTVjMDJiMDIzYWMxMzE3 YjUyNjc3MGJkNmQ3YzM4MzE5MTY2NDkyIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxNyBAQAorMjAxOS0wMS0xNCAgS2VpdGggTWlsbGVyICA8a2VpdGhfbWlsbGVyQGFwcGxl LmNvbT4KKworICAgICAgICBKU1NjcmlwdCBBUEkgc2hvdWxkIG9ubHkgdGFrZSBhc2NpaSBmaWxl cy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE5MzQy MAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogQVBJ L0pTU2NyaXB0Lmg6CisgICAgICAgICogQVBJL0pTU2NyaXB0Lm1tOgorICAgICAgICAoK1tKU1Nj cmlwdCBzY3JpcHRGcm9tQVNDSUlGaWxlOmluVmlydHVhbE1hY2hpbmU6d2l0aENvZGVTaWduaW5n OmFuZEJ5dGVjb2RlQ2FjaGU6XSk6CisgICAgICAgICgrW0pTU2NyaXB0IHNjcmlwdEZyb21VVEY4 RmlsZTppblZpcnR1YWxNYWNoaW5lOndpdGhDb2RlU2lnbmluZzphbmRCeXRlY29kZUNhY2hlOl0p OiBEZWxldGVkLgorICAgICAgICAqIEFQSS90ZXN0cy90ZXN0YXBpLm1tOgorICAgICAgICAoLVtK U0NvbnRleHRGaWxlTG9hZGVyRGVsZWdhdGUgY29udGV4dDpmZXRjaE1vZHVsZUZvcklkZW50aWZp ZXI6d2l0aFJlc29sdmVIYW5kbGVyOmFuZFJlamVjdEhhbmRsZXI6XSk6CisKIDIwMTktMDEtMTQg IEtlaXRoIE1pbGxlciAgPGtlaXRoX21pbGxlckBhcHBsZS5jb20+CiAKICAgICAgICAgSlNDIHNo b3VsZCBoYXZlIGEgbW9kdWxlIGxvYWRlciBBUEkKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2Ny aXB0Q29yZS9BUEkvSlNTY3JpcHQuaCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9BUEkvSlNTY3Jp cHQuaAppbmRleCA5MGNiNjA5MDg4ZWM4MmY3NDRhYTcyYTdjZDdjMWQ4ZTEzODUzYzg3Li44NzU3 MGUzMDA1MmFhZDFjNjYzMWExNmQ2OWQ4MmJjYjkwNTk0ZTMxIDEwMDY0NAotLS0gYS9Tb3VyY2Uv SmF2YVNjcmlwdENvcmUvQVBJL0pTU2NyaXB0LmgKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3Jl L0FQSS9KU1NjcmlwdC5oCkBAIC01Miw4ICs1MiwxMCBAQCBKU0NfQ0xBU1NfQVZBSUxBQkxFKG1h Y29zeChKU0NfTUFDX1RCQSksIGlvcyhKU0NfSU9TX1RCQSkpCiAgQHBhcmFtIGNhY2hlUGF0aCBB IFVSTCBjb250YWluaW5nIHRoZSBwYXRoIHdoZXJlIHRoZSBWTSBzaG91bGQgY2FjaGUgZm9yIGZ1 dHVyZSBleGVjdXRpb24uCiAgQHJlc3VsdCBUaGUgbmV3IHNjcmlwdC4KICBAZGlzY3Vzc2lvbiB0 aGUgZmlsZXMgYXQgZmlsZVBhdGgsIGNvZGVTaWduaW5nUGF0aCwgYW5kIGNhY2hlUGF0aCBzaG91 bGQgbm90IGJlIGV4dGVybmFsbHkgbW9kaWZpZWQgIGZvciB0aGUgbGlmZWN5Y2xlIG9mIHZtLiBO b3RlIHRoYXQgY29kZVNpZ25pbmdQYXRoIGFuZCBjYWNoZVBhdGggYXJlIG5vdCB1c2VkIGN1cnJl bnRseSwgYnV0IHRoYXQgd2lsbCBjaGFuZ2UgaW4gdGhlIG5lYXIgZnV0dXJlLgorCisgSWYgdGhl IGZpbGUgYXQgZmlsZVBhdGggaXMgbm90IGFzY2lpIHRoaXMgbWV0aG9kIHdpbGwgcmV0dXJuIG5p bC4KICAqLwotKyAobnVsbGFibGUgaW5zdGFuY2V0eXBlKXNjcmlwdEZyb21VVEY4RmlsZTooTlNV UkwgKilmaWxlUGF0aCBpblZpcnR1YWxNYWNoaW5lOihKU1ZpcnR1YWxNYWNoaW5lICopdm0gd2l0 aENvZGVTaWduaW5nOihudWxsYWJsZSBOU1VSTCAqKWNvZGVTaWduaW5nUGF0aCBhbmRCeXRlY29k ZUNhY2hlOihudWxsYWJsZSBOU1VSTCAqKWNhY2hlUGF0aDsKKysgKG51bGxhYmxlIGluc3RhbmNl dHlwZSlzY3JpcHRGcm9tQVNDSUlGaWxlOihOU1VSTCAqKWZpbGVQYXRoIGluVmlydHVhbE1hY2hp bmU6KEpTVmlydHVhbE1hY2hpbmUgKil2bSB3aXRoQ29kZVNpZ25pbmc6KG51bGxhYmxlIE5TVVJM ICopY29kZVNpZ25pbmdQYXRoIGFuZEJ5dGVjb2RlQ2FjaGU6KG51bGxhYmxlIE5TVVJMICopY2Fj aGVQYXRoOwogCiBAZW5kCiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9BUEkv SlNTY3JpcHQubW0gYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQVBJL0pTU2NyaXB0Lm1tCmluZGV4 IDc5NmM0MWVmOWVjYzM5ODQ3MDA2Y2ZiMWI2NTczYzUzNDlkM2ZkZGQuLmFkMmM2YzVlMmQxYzhi MTBiOTc1MTZmMTNkNWYxYmI1YjU4ZDg2ZjkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS9BUEkvSlNTY3JpcHQubW0KKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0FQSS9KU1Nj cmlwdC5tbQpAQCAtNzcsNyArNzcsNyBAQCBzdGF0aWMgYm9vbCBmaWxsQnVmZmVyV2l0aENvbnRl bnRzT2ZGaWxlKGNvbnN0IFN0cmluZyYgZmlsZU5hbWUsIFZlY3RvcjxjaGFyPiYgYgogfQogCiAK LSsgKGluc3RhbmNldHlwZSlzY3JpcHRGcm9tVVRGOEZpbGU6KE5TVVJMICopZmlsZVBhdGggaW5W aXJ0dWFsTWFjaGluZTooSlNWaXJ0dWFsTWFjaGluZSAqKXZtIHdpdGhDb2RlU2lnbmluZzooTlNV UkwgKiljb2RlU2lnbmluZ1BhdGggYW5kQnl0ZWNvZGVDYWNoZTooTlNVUkwgKiljYWNoZVBhdGgK KysgKGluc3RhbmNldHlwZSlzY3JpcHRGcm9tQVNDSUlGaWxlOihOU1VSTCAqKWZpbGVQYXRoIGlu VmlydHVhbE1hY2hpbmU6KEpTVmlydHVhbE1hY2hpbmUgKil2bSB3aXRoQ29kZVNpZ25pbmc6KE5T VVJMICopY29kZVNpZ25pbmdQYXRoIGFuZEJ5dGVjb2RlQ2FjaGU6KE5TVVJMICopY2FjaGVQYXRo CiB7CiAgICAgLy8gRklYTUU6IFRoaXMgc2hvdWxkIGNoZWNrIGNvZGVTaWduaW5nLgogICAgIFVO VVNFRF9QQVJBTShjb2RlU2lnbmluZ1BhdGgpOwpAQCAtOTIsNiArOTIsMTEgQEAgc3RhdGljIGJv b2wgZmlsbEJ1ZmZlcldpdGhDb250ZW50c09mRmlsZShjb25zdCBTdHJpbmcmIGZpbGVOYW1lLCBW ZWN0b3I8Y2hhcj4mIGIKICAgICBpZiAoIWZpbGxCdWZmZXJXaXRoQ29udGVudHNPZkZpbGUoZmls ZVBhdGhVUkwuZmlsZVN5c3RlbVBhdGgoKSwgYnVmZmVyKSkKICAgICAgICAgcmV0dXJuIG5pbDsK IAorICAgIGZvciAoY2hhciBjIDogYnVmZmVyKSB7CisgICAgICAgIGlmICghaXNBU0NJSShjKSkK KyAgICAgICAgICAgIHJldHVybiBuaWw7CisgICAgfQorCiAgICAgSlNTY3JpcHQgKnJlc3VsdCA9 IFtbSlNTY3JpcHQgYWxsb2NdIGluaXRdOwogICAgIHJlc3VsdC0+bV9zb3VyY2UgPSBTdHJpbmc6 OmZyb21VVEY4V2l0aExhdGluMUZhbGxiYWNrKGJ1ZmZlci5kYXRhKCksIGJ1ZmZlci5zaXplKCkp OwogICAgIHJldHVybiByZXN1bHQ7CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUv QVBJL3Rlc3RzL3Rlc3RhcGkubW0gYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQVBJL3Rlc3RzL3Rl c3RhcGkubW0KaW5kZXggNDM1ZmRiYjM2ZDI0NDZlODVkYjUzMTM2MzNjZDc2NGZlZjc5OThiMC4u MTNiZWI2OWYyYmNkNzIxOTRjNzBhZjU2OGY5NjEyZDYxZWY2YWNjMyAxMDA2NDQKLS0tIGEvU291 cmNlL0phdmFTY3JpcHRDb3JlL0FQSS90ZXN0cy90ZXN0YXBpLm1tCisrKyBiL1NvdXJjZS9KYXZh U2NyaXB0Q29yZS9BUEkvdGVzdHMvdGVzdGFwaS5tbQpAQCAtMjAxNyw3ICsyMDE3LDcgQEAgc3Rh dGljIE5TVVJMICpyZXNvbHZlUGF0aFRvU2NyaXB0cygpCiAtICh2b2lkKWNvbnRleHQ6KEpTQ29u dGV4dCAqKWNvbnRleHQgZmV0Y2hNb2R1bGVGb3JJZGVudGlmaWVyOihKU1ZhbHVlICopaWRlbnRp ZmllciB3aXRoUmVzb2x2ZUhhbmRsZXI6KEpTVmFsdWUgKilyZXNvbHZlIGFuZFJlamVjdEhhbmRs ZXI6KEpTVmFsdWUgKilyZWplY3QKIHsKICAgICBOU1VSTCAqZmlsZVBhdGggPSBbTlNVUkwgVVJM V2l0aFN0cmluZzpbaWRlbnRpZmllciB0b1N0cmluZ11dOwotICAgIGF1dG8gKnNjcmlwdCA9IFtK U1NjcmlwdCBzY3JpcHRGcm9tVVRGOEZpbGU6ZmlsZVBhdGggaW5WaXJ0dWFsTWFjaGluZTpbY29u dGV4dCB2aXJ0dWFsTWFjaGluZV0gd2l0aENvZGVTaWduaW5nOm5pbCBhbmRCeXRlY29kZUNhY2hl Om5pbF07CisgICAgYXV0byAqc2NyaXB0ID0gW0pTU2NyaXB0IHNjcmlwdEZyb21BU0NJSUZpbGU6 ZmlsZVBhdGggaW5WaXJ0dWFsTWFjaGluZTpbY29udGV4dCB2aXJ0dWFsTWFjaGluZV0gd2l0aENv ZGVTaWduaW5nOm5pbCBhbmRCeXRlY29kZUNhY2hlOm5pbF07CiAgICAgaWYgKHNjcmlwdCkKICAg ICAgICAgW3Jlc29sdmUgY2FsbFdpdGhBcmd1bWVudHM6QFtzY3JpcHRdXTsKICAgICBlbHNlCg== 359574 2019-01-18 18:57:56 -0800 2019-01-18 19:35:50 -0800 Patch for landing bug-193420-20190118185755.patch text/plain 5651 keith_miller U3VidmVyc2lvbiBSZXZpc2lvbjogMjM5OTMzCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBk MGE1ODMyNzRiMGQ4ZjE5NzllNDMzOTAxYTRlZWIwMDIxZDQ5OTY3Li40YmQzOWIxNDY0OWVjMDMy MTE3NWYzZjhiNWFkMDk4ZjNlZTA1OTRkIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwyMSBAQAorMjAxOS0wMS0xOCAgS2VpdGggTWlsbGVyICA8a2VpdGhfbWlsbGVyQGFwcGxl LmNvbT4KKworICAgICAgICBKU1NjcmlwdCBBUEkgc2hvdWxkIG9ubHkgdGFrZSBhc2NpaSBmaWxl cy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE5MzQy MAorCisgICAgICAgIFJldmlld2VkIGJ5IFNhYW0gQmFyYXRpLgorCisgICAgICAgIFRoaXMgcGF0 Y2ggbGVhdmVzIHRoZSBVVEY4IG1ldGhvZCBmb3IgYmluYXJ5IGNvbXBhdGFibGl0eSwgd2hpY2gK KyAgICAgICAgd2lsbCBiZSByZW1vdmVkIGxhdGVyLgorCisgICAgICAgICogQVBJL0pTU2NyaXB0 Lmg6CisgICAgICAgICogQVBJL0pTU2NyaXB0Lm1tOgorICAgICAgICAoZmlsbEJ1ZmZlcldpdGhD b250ZW50c09mRmlsZSk6CisgICAgICAgICgrW0pTU2NyaXB0IHNjcmlwdEZyb21BU0NJSUZpbGU6 aW5WaXJ0dWFsTWFjaGluZTp3aXRoQ29kZVNpZ25pbmc6YW5kQnl0ZWNvZGVDYWNoZTpdKToKKyAg ICAgICAgKCtbSlNTY3JpcHQgc2NyaXB0RnJvbVVURjhGaWxlOmluVmlydHVhbE1hY2hpbmU6d2l0 aENvZGVTaWduaW5nOmFuZEJ5dGVjb2RlQ2FjaGU6XSk6CisgICAgICAgICogQVBJL3Rlc3RzL3Rl c3RhcGkubW06CisgICAgICAgICgtW0pTQ29udGV4dEZpbGVMb2FkZXJEZWxlZ2F0ZSBjb250ZXh0 OmZldGNoTW9kdWxlRm9ySWRlbnRpZmllcjp3aXRoUmVzb2x2ZUhhbmRsZXI6YW5kUmVqZWN0SGFu ZGxlcjpdKToKKwogMjAxOS0wMS0xNCAgS2VpdGggTWlsbGVyICA8a2VpdGhfbWlsbGVyQGFwcGxl LmNvbT4KIAogICAgICAgICBKU0Mgc2hvdWxkIGhhdmUgYSBtb2R1bGUgbG9hZGVyIEFQSQpkaWZm IC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL0FQSS9KU1NjcmlwdC5oIGIvU291cmNlL0ph dmFTY3JpcHRDb3JlL0FQSS9KU1NjcmlwdC5oCmluZGV4IDkwY2I2MDkwODhlYzgyZjc0NGFhNzJh N2NkN2MxZDhlMTM4NTNjODcuLjhkZWQ3Y2E3NzBlZmMxYjg3MWRiMDRmMjQ1ZGI1NTMxYzYxN2Q0 ZTEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9BUEkvSlNTY3JpcHQuaAorKysg Yi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQVBJL0pTU2NyaXB0LmgKQEAgLTUyLDYgKzUyLDE0IEBA IEpTQ19DTEFTU19BVkFJTEFCTEUobWFjb3N4KEpTQ19NQUNfVEJBKSwgaW9zKEpTQ19JT1NfVEJB KSkKICBAcGFyYW0gY2FjaGVQYXRoIEEgVVJMIGNvbnRhaW5pbmcgdGhlIHBhdGggd2hlcmUgdGhl IFZNIHNob3VsZCBjYWNoZSBmb3IgZnV0dXJlIGV4ZWN1dGlvbi4KICBAcmVzdWx0IFRoZSBuZXcg c2NyaXB0LgogIEBkaXNjdXNzaW9uIHRoZSBmaWxlcyBhdCBmaWxlUGF0aCwgY29kZVNpZ25pbmdQ YXRoLCBhbmQgY2FjaGVQYXRoIHNob3VsZCBub3QgYmUgZXh0ZXJuYWxseSBtb2RpZmllZCAgZm9y IHRoZSBsaWZlY3ljbGUgb2Ygdm0uIE5vdGUgdGhhdCBjb2RlU2lnbmluZ1BhdGggYW5kIGNhY2hl UGF0aCBhcmUgbm90IHVzZWQgY3VycmVudGx5LCBidXQgdGhhdCB3aWxsIGNoYW5nZSBpbiB0aGUg bmVhciBmdXR1cmUuCisKKyBJZiB0aGUgZmlsZSBhdCBmaWxlUGF0aCBpcyBub3QgYXNjaWkgdGhp cyBtZXRob2Qgd2lsbCByZXR1cm4gbmlsLgorICovCisrIChudWxsYWJsZSBpbnN0YW5jZXR5cGUp c2NyaXB0RnJvbUFTQ0lJRmlsZTooTlNVUkwgKilmaWxlUGF0aCBpblZpcnR1YWxNYWNoaW5lOihK U1ZpcnR1YWxNYWNoaW5lICopdm0gd2l0aENvZGVTaWduaW5nOihudWxsYWJsZSBOU1VSTCAqKWNv ZGVTaWduaW5nUGF0aCBhbmRCeXRlY29kZUNhY2hlOihudWxsYWJsZSBOU1VSTCAqKWNhY2hlUGF0 aDsKKworCisvKiEKKyBUaGlzIGlzIGRlcHJlY2F0ZWQgYW5kIGlzIGVxdWl2YWxlbnQgdG8gc2Ny aXB0RnJvbUFTQ0lJRmlsZTppblZpcnR1YWxNYWNoaW5lOndpdGhDb2RlU2lnbmluZzphbmRCeXRl Y29kZUNhY2hlOi4KICAqLwogKyAobnVsbGFibGUgaW5zdGFuY2V0eXBlKXNjcmlwdEZyb21VVEY4 RmlsZTooTlNVUkwgKilmaWxlUGF0aCBpblZpcnR1YWxNYWNoaW5lOihKU1ZpcnR1YWxNYWNoaW5l ICopdm0gd2l0aENvZGVTaWduaW5nOihudWxsYWJsZSBOU1VSTCAqKWNvZGVTaWduaW5nUGF0aCBh bmRCeXRlY29kZUNhY2hlOihudWxsYWJsZSBOU1VSTCAqKWNhY2hlUGF0aDsKIApkaWZmIC0tZ2l0 IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL0FQSS9KU1NjcmlwdC5tbSBiL1NvdXJjZS9KYXZhU2Ny aXB0Q29yZS9BUEkvSlNTY3JpcHQubW0KaW5kZXggNzk2YzQxZWY5ZWNjMzk4NDcwMDZjZmIxYjY1 NzNjNTM0OWQzZmRkZC4uZjdlOTM5YWYwOThiZjVkMGY1M2VkMWU4YjMyZDc1YTRkODIzZmQ3ZiAx MDA2NDQKLS0tIGEvU291cmNlL0phdmFTY3JpcHRDb3JlL0FQSS9KU1NjcmlwdC5tbQorKysgYi9T b3VyY2UvSmF2YVNjcmlwdENvcmUvQVBJL0pTU2NyaXB0Lm1tCkBAIC02Miw3ICs2Miw3IEBAIHN0 YXRpYyBib29sIGZpbGxCdWZmZXJXaXRoQ29udGVudHNPZkZpbGUoRklMRSogZmlsZSwgVmVjdG9y JiBidWZmZXIpCiAgICAgcmV0dXJuIHJlYWRTaXplID09IGJ1ZmZlci5zaXplKCkgLSBpbml0aWFs U2l6ZTsKIH0KIAotc3RhdGljIGJvb2wgZmlsbEJ1ZmZlcldpdGhDb250ZW50c09mRmlsZShjb25z dCBTdHJpbmcmIGZpbGVOYW1lLCBWZWN0b3I8Y2hhcj4mIGJ1ZmZlcikKK3N0YXRpYyBib29sIGZp bGxCdWZmZXJXaXRoQ29udGVudHNPZkZpbGUoY29uc3QgU3RyaW5nJiBmaWxlTmFtZSwgVmVjdG9y PExDaGFyPiYgYnVmZmVyKQogewogICAgIEZJTEUqIGYgPSBmb3BlbihmaWxlTmFtZS51dGY4KCku ZGF0YSgpLCAicmIiKTsKICAgICBpZiAoIWYpIHsKQEAgLTc3LDcgKzc3LDcgQEAgc3RhdGljIGJv b2wgZmlsbEJ1ZmZlcldpdGhDb250ZW50c09mRmlsZShjb25zdCBTdHJpbmcmIGZpbGVOYW1lLCBW ZWN0b3I8Y2hhcj4mIGIKIH0KIAogCi0rIChpbnN0YW5jZXR5cGUpc2NyaXB0RnJvbVVURjhGaWxl OihOU1VSTCAqKWZpbGVQYXRoIGluVmlydHVhbE1hY2hpbmU6KEpTVmlydHVhbE1hY2hpbmUgKil2 bSB3aXRoQ29kZVNpZ25pbmc6KE5TVVJMICopY29kZVNpZ25pbmdQYXRoIGFuZEJ5dGVjb2RlQ2Fj aGU6KE5TVVJMICopY2FjaGVQYXRoCisrIChpbnN0YW5jZXR5cGUpc2NyaXB0RnJvbUFTQ0lJRmls ZTooTlNVUkwgKilmaWxlUGF0aCBpblZpcnR1YWxNYWNoaW5lOihKU1ZpcnR1YWxNYWNoaW5lICop dm0gd2l0aENvZGVTaWduaW5nOihOU1VSTCAqKWNvZGVTaWduaW5nUGF0aCBhbmRCeXRlY29kZUNh Y2hlOihOU1VSTCAqKWNhY2hlUGF0aAogewogICAgIC8vIEZJWE1FOiBUaGlzIHNob3VsZCBjaGVj ayBjb2RlU2lnbmluZy4KICAgICBVTlVTRURfUEFSQU0oY29kZVNpZ25pbmdQYXRoKTsKQEAgLTg4 LDE1ICs4OCwyMyBAQCBzdGF0aWMgYm9vbCBmaWxsQnVmZmVyV2l0aENvbnRlbnRzT2ZGaWxlKGNv bnN0IFN0cmluZyYgZmlsZU5hbWUsIFZlY3RvcjxjaGFyPiYgYgogICAgIGlmICghZmlsZVBhdGhV UkwuaXNMb2NhbEZpbGUoKSkKICAgICAgICAgcmV0dXJuIG5pbDsKICAgICAvLyBGSVhNRTogVGhp cyBzaG91bGQgbW1hcCB0aGUgY29udGVudHMgb2YgdGhlIGZpbGUgaW5zdGVhZCBvZiBjb3B5aW5n IGl0IGludG8gZGlydHkgbWVtb3J5LgotICAgIFZlY3RvcjxjaGFyPiBidWZmZXI7CisgICAgVmVj dG9yPExDaGFyPiBidWZmZXI7CiAgICAgaWYgKCFmaWxsQnVmZmVyV2l0aENvbnRlbnRzT2ZGaWxl KGZpbGVQYXRoVVJMLmZpbGVTeXN0ZW1QYXRoKCksIGJ1ZmZlcikpCiAgICAgICAgIHJldHVybiBu aWw7CiAKKyAgICBpZiAoIWNoYXJhY3RlcnNBcmVBbGxBU0NJSShidWZmZXIuZGF0YSgpLCBidWZm ZXIuc2l6ZSgpKSkKKyAgICAgICAgcmV0dXJuIG5pbDsKKwogICAgIEpTU2NyaXB0ICpyZXN1bHQg PSBbW0pTU2NyaXB0IGFsbG9jXSBpbml0XTsKICAgICByZXN1bHQtPm1fc291cmNlID0gU3RyaW5n Ojpmcm9tVVRGOFdpdGhMYXRpbjFGYWxsYmFjayhidWZmZXIuZGF0YSgpLCBidWZmZXIuc2l6ZSgp KTsKICAgICByZXR1cm4gcmVzdWx0OwogfQogCisrIChpbnN0YW5jZXR5cGUpc2NyaXB0RnJvbVVU RjhGaWxlOihOU1VSTCAqKWZpbGVQYXRoIGluVmlydHVhbE1hY2hpbmU6KEpTVmlydHVhbE1hY2hp bmUgKil2bSB3aXRoQ29kZVNpZ25pbmc6KE5TVVJMICopY29kZVNpZ25pbmdQYXRoIGFuZEJ5dGVj b2RlQ2FjaGU6KE5TVVJMICopY2FjaGVQYXRoCit7CisgICAgcmV0dXJuIFtKU1NjcmlwdCBzY3Jp cHRGcm9tQVNDSUlGaWxlOmZpbGVQYXRoIGluVmlydHVhbE1hY2hpbmU6dm0gd2l0aENvZGVTaWdu aW5nOmNvZGVTaWduaW5nUGF0aCBhbmRCeXRlY29kZUNhY2hlOmNhY2hlUGF0aF07Cit9CisKIGNv bnN0IFN0cmluZyYgZ2V0SlNTY3JpcHRTb3VyY2VDb2RlKEpTU2NyaXB0ICptb2R1bGUpIHsgcmV0 dXJuIG1vZHVsZS0+bV9zb3VyY2U7IH0KIAogQGVuZApkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFT Y3JpcHRDb3JlL0FQSS90ZXN0cy90ZXN0YXBpLm1tIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0FQ SS90ZXN0cy90ZXN0YXBpLm1tCmluZGV4IDQzNWZkYmIzNmQyNDQ2ZTg1ZGI1MzEzNjMzY2Q3NjRm ZWY3OTk4YjAuLjEzYmViNjlmMmJjZDcyMTk0YzcwYWY1NjhmOTYxMmQ2MWVmNmFjYzMgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9BUEkvdGVzdHMvdGVzdGFwaS5tbQorKysgYi9T b3VyY2UvSmF2YVNjcmlwdENvcmUvQVBJL3Rlc3RzL3Rlc3RhcGkubW0KQEAgLTIwMTcsNyArMjAx Nyw3IEBAIHN0YXRpYyBOU1VSTCAqcmVzb2x2ZVBhdGhUb1NjcmlwdHMoKQogLSAodm9pZCljb250 ZXh0OihKU0NvbnRleHQgKiljb250ZXh0IGZldGNoTW9kdWxlRm9ySWRlbnRpZmllcjooSlNWYWx1 ZSAqKWlkZW50aWZpZXIgd2l0aFJlc29sdmVIYW5kbGVyOihKU1ZhbHVlICopcmVzb2x2ZSBhbmRS ZWplY3RIYW5kbGVyOihKU1ZhbHVlICopcmVqZWN0CiB7CiAgICAgTlNVUkwgKmZpbGVQYXRoID0g W05TVVJMIFVSTFdpdGhTdHJpbmc6W2lkZW50aWZpZXIgdG9TdHJpbmddXTsKLSAgICBhdXRvICpz Y3JpcHQgPSBbSlNTY3JpcHQgc2NyaXB0RnJvbVVURjhGaWxlOmZpbGVQYXRoIGluVmlydHVhbE1h Y2hpbmU6W2NvbnRleHQgdmlydHVhbE1hY2hpbmVdIHdpdGhDb2RlU2lnbmluZzpuaWwgYW5kQnl0 ZWNvZGVDYWNoZTpuaWxdOworICAgIGF1dG8gKnNjcmlwdCA9IFtKU1NjcmlwdCBzY3JpcHRGcm9t QVNDSUlGaWxlOmZpbGVQYXRoIGluVmlydHVhbE1hY2hpbmU6W2NvbnRleHQgdmlydHVhbE1hY2hp bmVdIHdpdGhDb2RlU2lnbmluZzpuaWwgYW5kQnl0ZWNvZGVDYWNoZTpuaWxdOwogICAgIGlmIChz Y3JpcHQpCiAgICAgICAgIFtyZXNvbHZlIGNhbGxXaXRoQXJndW1lbnRzOkBbc2NyaXB0XV07CiAg ICAgZWxzZQo=