86811 2012-05-17 22:53:25 -0700 REGRESSION: We should allow null modificationTime when snapshot metadata is given 2012-05-30 02:09:05 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 kinuko kinuko abarth ap ericu eric jianli ojan satorux tbarzic webkit.review.bot oldest_to_newest 627361 0 kinuko 2012-05-17 22:53:25 -0700 [REGRESSION] we should not force file modificationTime check on (non-sliced) files even if snapshot time is given This is a regression introduced by r117432. http://trac.webkit.org/changeset/117432 627364 1 142637 kinuko 2012-05-17 22:57:49 -0700 Created attachment 142637 Patch 627373 2 kinuko 2012-05-17 23:11:55 -0700 A regression is resported by chrome os folks... Jian, could you take a look at this again? This patch is to avoid assigning the given snapshot modificationTime to BlobDataItem's expectedModificationTime, as assigning a non-null value there forces modificationTime check, and we wouldn't want to do that at least for non-sliced files. (This change would not look truly consistent but I have no better idea for now.) 627455 3 kinuko 2012-05-18 01:15:36 -0700 Clearing the r flag for now until we figure out what to do. 627960 4 ap 2012-05-18 12:58:41 -0700 Please do post a rationale when making a final patch. 628294 5 142637 kinuko 2012-05-18 17:40:48 -0700 Comment on attachment 142637 Patch Per offline conversation this fix seems to work and chromeos team will need this. Jian, could you take a look? Thanks! 628298 6 kinuko 2012-05-18 17:53:27 -0700 (In reply to comment #4) > Please do post a rationale when making a final patch. Non-null expectedModificationTime field must be given to the BlobDataItem only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. I wrongly set the value in the previous patch which caused undesirable modificationTime verification even on non-sliced files (when they are given by an external filesystem). This patch is trying to fix the regression issue. 628426 7 ap 2012-05-19 08:44:32 -0700 > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? 628433 8 kinuko 2012-05-19 09:23:19 -0700 (In reply to comment #7) > > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. > > Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? Sliced file is special, since slicing creates a new reference to a File. The spec says the UA must throw an error if the file has been modified after "a reference for the File is created", or "a read operation is initiated". Just creating a File object doesn't mean we should disallow any file changes on it, but once a read operation is initiated or the file is referenced (by another Blob by slicing) we need to detect file changes, as the reader would want to to make sure it is reading/referring the same one as its reference is created. 628437 9 ap 2012-05-19 09:34:52 -0700 Thank you for the explanation. 629596 10 ericu 2012-05-21 15:26:55 -0700 (In reply to comment #8) > (In reply to comment #7) > > > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. > > > > Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? > > Sliced file is special, since slicing creates a new reference to a File. > The spec says the UA must throw an error if the file has been modified after "a reference for the File is created", or "a read operation is initiated". Just creating a File object doesn't mean we should disallow any file changes on it, but once a read operation is initiated or the file is referenced (by another Blob by slicing) we need to detect file changes, as the reader would want to to make sure it is reading/referring the same one as its reference is created. I interpret the spec differently, and I don't see your text written there explicitly. Looking at the [non-normative] text there, I see: "...guarding against modifications of files on disk after a selection has taken place." That looks to me like we should actually grab the modification time when the File is first created. Ah, here's some normative text from the latest editor's draft: "For synchronous reads on a Web Worker [Workers], if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError; for asynchronous reads, user agents must fire an error event with the error attribute returning a NotReadableError DOMError." Where it says "the File object reference is created", that looks to me like "when we create the File", not "when we create a Blob that refers to the File". 629631 11 jianli 2012-05-21 15:45:25 -0700 (In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #7) > > > > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. > > > > > > Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? > > > > Sliced file is special, since slicing creates a new reference to a File. > > The spec says the UA must throw an error if the file has been modified after "a reference for the File is created", or "a read operation is initiated". Just creating a File object doesn't mean we should disallow any file changes on it, but once a read operation is initiated or the file is referenced (by another Blob by slicing) we need to detect file changes, as the reader would want to to make sure it is reading/referring the same one as its reference is created. > > I interpret the spec differently, and I don't see your text written there explicitly. Looking at the [non-normative] text there, I see: "...guarding against modifications of files on disk after a selection has taken place." That looks to me like we should actually grab the modification time when the File is first created. > > Ah, here's some normative text from the latest editor's draft: "For synchronous reads on a Web Worker [Workers], if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError; for asynchronous reads, user agents must fire an error event with the error attribute returning a NotReadableError DOMError." > > Where it says "the File object reference is created", that looks to me like "when we create the File", not "when we create a Blob that refers to the File". Yes, "Security Considerations" section does say: Post-selection file modifications occur when a file changes on disk after it has been selected. In such cases, user agents MAY throw a SecurityError for synchronous read methods, or return a SecurityError DOMError for asynchronous reads. However, the spec seems to indicate that File.lastModifiedDate and Blob.size should return the latest modification time and size. It did not say that some kind of error should be returned if the file has been changed since the file was selected. Currently getting lastModifiedDate and size are both synchronous operations, in order to be consistent with the old behavior. I am ok with changing the semantics if we think security concern does make sense. If so, we need to pass file size, modification time when files are selected. 629645 12 ericu 2012-05-21 15:50:47 -0700 (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. > > > > > > > > Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? > > > > > > Sliced file is special, since slicing creates a new reference to a File. > > > The spec says the UA must throw an error if the file has been modified after "a reference for the File is created", or "a read operation is initiated". Just creating a File object doesn't mean we should disallow any file changes on it, but once a read operation is initiated or the file is referenced (by another Blob by slicing) we need to detect file changes, as the reader would want to to make sure it is reading/referring the same one as its reference is created. > > > > I interpret the spec differently, and I don't see your text written there explicitly. Looking at the [non-normative] text there, I see: "...guarding against modifications of files on disk after a selection has taken place." That looks to me like we should actually grab the modification time when the File is first created. > > > > Ah, here's some normative text from the latest editor's draft: "For synchronous reads on a Web Worker [Workers], if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError; for asynchronous reads, user agents must fire an error event with the error attribute returning a NotReadableError DOMError." > > > > Where it says "the File object reference is created", that looks to me like "when we create the File", not "when we create a Blob that refers to the File". > > Yes, "Security Considerations" section does say: > Post-selection file modifications occur when a file changes on disk after it has been selected. In such cases, user agents MAY throw a SecurityError for synchronous read methods, or return a SecurityError DOMError for asynchronous reads. > > However, the spec seems to indicate that File.lastModifiedDate and Blob.size should return the latest modification time and size. It did not say that some kind of error should be returned if the file has been changed since the file was selected. Currently getting lastModifiedDate and size are both synchronous operations, in order to be consistent with the old behavior. It does say that we have the option to return null for those attributes. I think the spec's just letting this fall through the cracks: we should throw an exception if it's changed and you try to use it, but we should also report mod time correctly if we can. I think that's a spec bug, so I'll post to public-webapps. > I am ok with changing the semantics if we think security concern does make sense. If so, we need to pass file size, modification time when files are selected. I think the security concern does make sense; let's see what happens on public-webapps. 629923 13 kinuko 2012-05-21 21:22:40 -0700 (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #8) > > > > (In reply to comment #7) > > > > > > only when we want to make sure the file is not modified since the Blob is made, and we do that only for sliced files. > > > > > > > > > > Why are sliced files special? It appears that reader would always care when the file changed beneath it, wouldn't it? > > > > > > > > Sliced file is special, since slicing creates a new reference to a File. > > > > The spec says the UA must throw an error if the file has been modified after "a reference for the File is created", or "a read operation is initiated". Just creating a File object doesn't mean we should disallow any file changes on it, but once a read operation is initiated or the file is referenced (by another Blob by slicing) we need to detect file changes, as the reader would want to to make sure it is reading/referring the same one as its reference is created. > > > > > > I interpret the spec differently, and I don't see your text written there explicitly. Looking at the [non-normative] text there, I see: "...guarding against modifications of files on disk after a selection has taken place." That looks to me like we should actually grab the modification time when the File is first created. > > > > > > Ah, here's some normative text from the latest editor's draft: "For synchronous reads on a Web Worker [Workers], if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError; for asynchronous reads, user agents must fire an error event with the error attribute returning a NotReadableError DOMError." > > > > > > Where it says "the File object reference is created", that looks to me like "when we create the File", not "when we create a Blob that refers to the File". I was initially interpreting like that, (and have once created a patch along the line since it'd simplify the implementation), but it also says "The File interface [...] represents file data that can be read into memory at the time a read operation is initiated" which makes me feel that when we capture the 'content' is not strictly combined to the object creation time. (And if we do so we could likely break many Web apps) The security concern makes sense, but it sounds like we should throw SecurityError rather than NotReadableError if post-selection file modification occurs. > > Yes, "Security Considerations" section does say: > > Post-selection file modifications occur when a file changes on disk after it has been selected. In such cases, user agents MAY throw a SecurityError for synchronous read methods, or return a SecurityError DOMError for asynchronous reads. > > > > However, the spec seems to indicate that File.lastModifiedDate and Blob.size should return the latest modification time and size. It did not say that some kind of error should be returned if the file has been changed since the file was selected. Currently getting lastModifiedDate and size are both synchronous operations, in order to be consistent with the old behavior. > > It does say that we have the option to return null for those attributes. I think the spec's just letting this fall through the cracks: we should throw an exception if it's changed and you try to use it, but we should also report mod time correctly if we can. I think that's a spec bug, so I'll post to public-webapps. > > > I am ok with changing the semantics if we think security concern does make sense. If so, we need to pass file size, modification time when files are selected. > > I think the security concern does make sense; let's see what happens on public-webapps. Yup we should make it clear on public-webapps. Thanks for posting on public-webapps. 631187 14 kinuko 2012-05-22 21:44:02 -0700 Looking at the discussion on public-webapps it looks whether we should treat sliced files specifically or not is a bit gray, though this patch still holds some rationale as it makes its behavior consistent to the current existing behavior. I can either 1. land this patch for consistency (possibly with FIXME) and make horizontal changes later when we reach a clear agreement on public-webapps, or 2. go ahead and assume we should just throw exception whether a file is sliced or not, but allow embedders to pass NULL modificationTime (since it's allowed to be NULL) Any thoughts? 631382 15 kinuko 2012-05-23 01:38:58 -0700 I think probably we should take option 2 (because regardless of whether it is sliced or not we should allow null modificationTime as valid metadata per spec). I'm updating the issue summary. 631386 16 143500 kinuko 2012-05-23 01:44:49 -0700 Created attachment 143500 Patch 631387 17 kinuko 2012-05-23 01:47:05 -0700 Jian, sorry for bothering you. I uploaded a new patch-- could you take a look? 632390 18 143720 kinuko 2012-05-23 21:04:18 -0700 Created attachment 143720 Patch Sorry the issue summary was telling the opposite. Updated the ChangeLog (and issue summary) 634067 19 143720 jianli 2012-05-25 10:56:09 -0700 Comment on attachment 143720 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=143720&action=review > Source/WebCore/ChangeLog:8 > + No new tests as this change is not for regular files/filesystems. Please describe the reason why we need to fix this. > Source/WebCore/fileapi/File.cpp:133 > + if (m_snapshotSize >= 0) It would be better if we can introduce a helper function like isValidSnapshot so that we have one centralized place to perform this check and you can put comment there. > Source/WebCore/fileapi/File.h:103 > + // If valid file metadata (whose length field is non-negative) is given at construction time we use the metadata in size(), lastModifiedTime() and webkitSlice(). nit: comma before "we use the ..." > Source/WebCore/fileapi/File.h:105 > + // Note that we may return null lastModifiedTime if it is given (together with positive file length). The whole comment is a bit confusing. How about rephrasing to something like: // If m_snapShotSize is negative (initialized to -1 by default), the snapshot metadata is invalid and we retrieve the latest metadata synchronously in size(), lastModifiedTime() and webkitSlice(). Otherwise, the valid snapshot metadata can be used directly in those methods. // Note that the valid snapshot metadata could have non-negative size and null modified time which mean that ...... 635196 20 144354 kinuko 2012-05-28 07:11:02 -0700 Created attachment 144354 Patch 635198 21 143720 kinuko 2012-05-28 07:11:32 -0700 Comment on attachment 143720 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=143720&action=review >> Source/WebCore/ChangeLog:8 >> + No new tests as this change is not for regular files/filesystems. > > Please describe the reason why we need to fix this. Done. >> Source/WebCore/fileapi/File.cpp:133 >> + if (m_snapshotSize >= 0) > > It would be better if we can introduce a helper function like isValidSnapshot so that we have one centralized place to perform this check and you can put comment there. Done. >> Source/WebCore/fileapi/File.h:105 >> + // Note that we may return null lastModifiedTime if it is given (together with positive file length). > > The whole comment is a bit confusing. How about rephrasing to something like: > // If m_snapShotSize is negative (initialized to -1 by default), the snapshot metadata is invalid and we retrieve the latest metadata synchronously in size(), lastModifiedTime() and webkitSlice(). Otherwise, the valid snapshot metadata can be used directly in those methods. > // Note that the valid snapshot metadata could have non-negative size and null modified time which mean that ...... Updated as suggested. Thanks! 635818 22 144354 kinuko 2012-05-29 03:19:43 -0700 Comment on attachment 144354 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144354&action=review > Source/WebCore/ChangeLog:20 > + File.idl but will fix in another patch.) The change for this FIXME is: https://bugs.webkit.org/show_bug.cgi?id=87709 I'll remove the FIXME if the other one gets in earlier. 636154 23 144354 jianli 2012-05-29 09:59:04 -0700 Comment on attachment 144354 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144354&action=review > Source/WebCore/ChangeLog:14 > + 2. it is valid per spec whether it indicates(http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate says the nit: "whether it indicates" seems to be redundant. 637043 24 kinuko 2012-05-30 02:09:05 -0700 Committed r118907: <http://trac.webkit.org/changeset/118907> 142637 2012-05-17 22:57:49 -0700 2012-05-23 01:44:43 -0700 Patch bug-86811-20120518145747.patch text/plain 1616 kinuko U3VidmVyc2lvbiBSZXZpc2lvbjogMTE3NDU2CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggYjRjMmEzM2ZkZGM1MmJi N2YzMDdkNGYzMDkyNWU1Y2MwODk2ZTQxMS4uZDIxYmE1YWU5Yzk0YTY0ZTZkNDkzOTE1Zjk2ODMw YzE3YzU4ODk5ZSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDEyLTA1LTE3ICBLaW51 a28gWWFzdWRhICA8a2ludWtvQGNocm9taXVtLm9yZz4KKworICAgICAgICBbUkVHUkVTU0lPTl0g d2Ugc2hvdWxkIG5vdCBmb3JjZSBmaWxlIG1vZGlmaWNhdGlvblRpbWUgY2hlY2sgb24gKG5vbi1z bGljZWQpIGZpbGVzIGV2ZW4gaWYgc25hcHNob3QgdGltZSBpcyBnaXZlbgorICAgICAgICBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODY4MTEKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBObyBuZXcgdGVzdHMgYXMgdGhpcyBj aGFuZ2UgaXMgbm90IGZvciByZWd1bGFyIGZpbGVzL2ZpbGVzeXN0ZW1zLgorICAgICAgICAoVGVz dHMgaW4gQ2hyb21lIE9TIHBvcnQgc2hvdWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRoaXMpCisKKyAg ICAgICAgKiBmaWxlYXBpL0ZpbGUuY3BwOgorICAgICAgICAoV2ViQ29yZTo6Y3JlYXRlQmxvYkRh dGFGb3JGaWxlV2l0aE1ldGFkYXRhKToKKwogMjAxMi0wNS0xNyAgUGF2ZWwgRmVsZG1hbiAgPHBm ZWxkbWFuQGNocm9taXVtLm9yZz4KIAogICAgICAgICBXZWIgSW5zcGVjdG9yOiBjcmVhdGUgU291 cmNlRnJhbWVzIHdpdGggY29udGVudCBwcm92aWRlcnMuCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2Vi Q29yZS9maWxlYXBpL0ZpbGUuY3BwIGIvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmNwcApp bmRleCBmMmFmYTM0NTRhMGNkMzNjZjYxN2M0MDQ3OTY4ZWFlOTk3YzBlZDE0Li45MmYyYjMxODhk YTdhNDc0ZWNlNzhiYWJmNmQzYzc1NjZmZDkwMWY5IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9maWxlYXBpL0ZpbGUuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5jcHAK QEAgLTY2LDcgKzY2LDcgQEAgc3RhdGljIFBhc3NPd25QdHI8QmxvYkRhdGE+IGNyZWF0ZUJsb2JE YXRhRm9yRmlsZVdpdGhNZXRhZGF0YShjb25zdCBTdHJpbmcmIGZpbGUKIHsKICAgICBPd25QdHI8 QmxvYkRhdGE+IGJsb2JEYXRhID0gQmxvYkRhdGE6OmNyZWF0ZSgpOwogICAgIGJsb2JEYXRhLT5z ZXRDb250ZW50VHlwZShnZXRDb250ZW50VHlwZUZyb21GaWxlTmFtZShmaWxlU3lzdGVtTmFtZSkp OwotICAgIGJsb2JEYXRhLT5hcHBlbmRGaWxlKG1ldGFkYXRhLnBsYXRmb3JtUGF0aCwgMCwgbWV0 YWRhdGEubGVuZ3RoLCBtZXRhZGF0YS5tb2RpZmljYXRpb25UaW1lKTsKKyAgICBibG9iRGF0YS0+ YXBwZW5kRmlsZShtZXRhZGF0YS5wbGF0Zm9ybVBhdGgsIDAsIG1ldGFkYXRhLmxlbmd0aCwgQmxv YkRhdGFJdGVtOjpkb05vdENoZWNrRmlsZUNoYW5nZSk7CiAgICAgcmV0dXJuIGJsb2JEYXRhLnJl bGVhc2UoKTsKIH0KICNlbmRpZgo= 143500 2012-05-23 01:44:49 -0700 2012-05-23 21:04:13 -0700 Patch bug-86811-20120523174447.patch text/plain 3898 kinuko U3VidmVyc2lvbiBSZXZpc2lvbjogMTE3NDU2CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggYjRjMmEzM2ZkZGM1MmJi N2YzMDdkNGYzMDkyNWU1Y2MwODk2ZTQxMS4uNjE2MzljMGYzMzBmMzIwODU4NzJmYzZhNWQzNTM2 ZjA0MGQxZTY2ZCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIwIEBACisyMDEyLTA1LTIzICBLaW51 a28gWWFzdWRhICA8a2ludWtvQGNocm9taXVtLm9yZz4KKworICAgICAgICBSRUdSRVNTSU9OOiBX ZSBzaG91bGQgbm90IGFsbG93IG51bGwgbW9kaWZpY2F0aW9uVGltZSB3aGVuIHNuYXBzaG90IG1l dGFkYXRhIGlzIGdpdmVuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn LmNnaT9pZD04NjgxMQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIE5vIG5ldyB0ZXN0cyBhcyB0aGlzIGNoYW5nZSBpcyBub3QgZm9yIHJlZ3VsYXIgZmls ZXMvZmlsZXN5c3RlbXMuCisgICAgICAgIChUZXN0cyBpbiBDaHJvbWUgT1MgcG9ydCBzaG91bGQg YmUgYWJsZSB0byB2ZXJpZnkgdGhpcykKKworICAgICAgICAqIGZpbGVhcGkvRmlsZS5jcHA6Cisg ICAgICAgIChXZWJDb3JlOjpGaWxlOjpsYXN0TW9kaWZpZWREYXRlKToKKyAgICAgICAgKFdlYkNv cmU6OkZpbGU6OnNpemUpOgorICAgICAgICAoV2ViQ29yZTo6RmlsZTo6Y2FwdHVyZVNuYXBzaG90 KToKKyAgICAgICAgKiBmaWxlYXBpL0ZpbGUuaDoKKyAgICAgICAgKEZpbGUpOgorCiAyMDEyLTA1 LTE3ICBQYXZlbCBGZWxkbWFuICA8cGZlbGRtYW5AY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFdl YiBJbnNwZWN0b3I6IGNyZWF0ZSBTb3VyY2VGcmFtZXMgd2l0aCBjb250ZW50IHByb3ZpZGVycy4K ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5jcHAgYi9Tb3VyY2UvV2Vi Q29yZS9maWxlYXBpL0ZpbGUuY3BwCmluZGV4IGYyYWZhMzQ1NGEwY2QzM2NmNjE3YzQwNDc5Njhl YWU5OTdjMGVkMTQuLmRlMjFhYTUzMTEzZmM2NzEwZTdlZWZhZGJhZDE4NTA5ZDMxODJhNTYgMTAw NjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5jcHAKKysrIGIvU291cmNlL1dl YkNvcmUvZmlsZWFwaS9GaWxlLmNwcApAQCAtMTMwLDcgKzEzMCw3IEBAIEZpbGU6OkZpbGUoY29u c3QgU3RyaW5nJiBuYW1lLCBjb25zdCBGaWxlTWV0YWRhdGEmIG1ldGFkYXRhKQogZG91YmxlIEZp bGU6Omxhc3RNb2RpZmllZERhdGUoKSBjb25zdAogewogI2lmIEVOQUJMRShGSUxFX1NZU1RFTSkK LSAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCAmJiBtX3NuYXBzaG90TW9kaWZpY2F0aW9uVGlt ZSkKKyAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCkKICAgICAgICAgcmV0dXJuIG1fc25hcHNo b3RNb2RpZmljYXRpb25UaW1lICogMTAwMC4wOwogI2VuZGlmCiAKQEAgLTE0NSw3ICsxNDUsNyBA QCBkb3VibGUgRmlsZTo6bGFzdE1vZGlmaWVkRGF0ZSgpIGNvbnN0CiB1bnNpZ25lZCBsb25nIGxv bmcgRmlsZTo6c2l6ZSgpIGNvbnN0CiB7CiAjaWYgRU5BQkxFKEZJTEVfU1lTVEVNKQotICAgIGlm IChtX3NuYXBzaG90U2l6ZSA+PSAwICYmIG1fc25hcHNob3RNb2RpZmljYXRpb25UaW1lKQorICAg IGlmIChtX3NuYXBzaG90U2l6ZSA+PSAwKQogICAgICAgICByZXR1cm4gbV9zbmFwc2hvdFNpemU7 CiAjZW5kaWYKIApAQCAtMTYwLDcgKzE2MCw3IEBAIHVuc2lnbmVkIGxvbmcgbG9uZyBGaWxlOjpz aXplKCkgY29uc3QKIHZvaWQgRmlsZTo6Y2FwdHVyZVNuYXBzaG90KGxvbmcgbG9uZyYgc25hcHNo b3RTaXplLCBkb3VibGUmIHNuYXBzaG90TW9kaWZpY2F0aW9uVGltZSkgY29uc3QKIHsKICNpZiBF TkFCTEUoRklMRV9TWVNURU0pCi0gICAgaWYgKG1fc25hcHNob3RTaXplID49IDAgJiYgbV9zbmFw c2hvdE1vZGlmaWNhdGlvblRpbWUpIHsKKyAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCkgewog ICAgICAgICBzbmFwc2hvdFNpemUgPSBtX3NuYXBzaG90U2l6ZTsKICAgICAgICAgc25hcHNob3RN b2RpZmljYXRpb25UaW1lID0gbV9zbmFwc2hvdE1vZGlmaWNhdGlvblRpbWU7CiAgICAgICAgIHJl dHVybjsKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5oIGIvU291cmNl L1dlYkNvcmUvZmlsZWFwaS9GaWxlLmgKaW5kZXggNjMzMWEyZDQ5OTc2NzJiNmZmMWI0ZDY2NmVh ZjQ3ZGM1MDk5NWQwMy4uYTBlYWJhMWQ4NjY4MzU2OTYzN2U0YTFhOWMwNTc1MmY1OWU5N2RmYiAx MDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmgKKysrIGIvU291cmNlL1dl YkNvcmUvZmlsZWFwaS9GaWxlLmgKQEAgLTU0LDcgKzU0LDcgQEAgcHVibGljOgogI2VuZGlmCiAK ICNpZiBFTkFCTEUoRklMRV9TWVNURU0pCi0gICAgLy8gSWYgZmlsZXN5c3RlbSBmaWxlcyBsaXZl IGluIHRoZSByZW1vdGUgZmlsZXN5c3RlbSwgdGhlIHBvcnQgbWlnaHQgcGFzcyB0aGUgdmFsaWQg bWV0YWRhdGEgKG5vbi16ZXJvIG1vZGlmaWNhdGlvblRpbWUgYW5kIG5vbi1uZWdhdGl2ZSBmaWxl IHNpemUpIGFuZCBjYWNoZSBpbiB0aGUgRmlsZSBvYmplY3QuCisgICAgLy8gSWYgZmlsZXN5c3Rl bSBmaWxlcyBsaXZlIGluIHRoZSByZW1vdGUgZmlsZXN5c3RlbSwgdGhlIHBvcnQgbWlnaHQgcGFz cyB0aGUgdmFsaWQgbWV0YWRhdGEgKHdob3NlIGxlbmd0aCBmaWVsZCBpcyBub24tbmVnYXRpdmUp IGFuZCBjYWNoZSBpbiB0aGUgRmlsZSBvYmplY3QuCiAgICAgLy8KICAgICAvLyBPdGhlcndpc2Ug Y2FsbGluZyBzaXplKCksIGxhc3RNb2RpZmllZFRpbWUoKSBhbmQgd2Via2l0U2xpY2UoKSB3aWxs IHN5bmNocm9ub3VzbHkgcXVlcnkgdGhlIGZpbGUgbWV0YWRhdGEuCiAgICAgc3RhdGljIFBhc3NS ZWZQdHI8RmlsZT4gY3JlYXRlRm9yRmlsZVN5c3RlbUZpbGUoY29uc3QgU3RyaW5nJiBuYW1lLCBj b25zdCBGaWxlTWV0YWRhdGEmIG1ldGFkYXRhKQpAQCAtMTAwLDggKzEwMCw5IEBAIHByaXZhdGU6 CiAgICAgU3RyaW5nIG1fbmFtZTsKIAogI2lmIEVOQUJMRShGSUxFX1NZU1RFTSkKLSAgICAvLyBJ ZiBub24temVybyBtb2RpZmljYXRpb25UaW1lIGFuZCBub24tbmVnYXRpdmUgZmlsZSBzaXplIGFy ZSBnaXZlbiBhdCBjb25zdHJ1Y3Rpb24gdGltZSB3ZSB1c2UgdGhlbSBpbiBzaXplKCksIGxhc3RN b2RpZmllZFRpbWUoKSBhbmQgd2Via2l0U2xpY2UoKS4KLSAgICAvLyBCeSBkZWZhdWx0IHdlIGlu aXRpYWxpemUgbV9zbmFwc2hvdFNpemUgdG8gLTEgYW5kIG1fc25hcHNob3RNb2RpZmljYXRpb25U aW1lIHRvIDAgKHNvIHRoYXQgd2UgZG9uJ3QgdXNlIHRoZW0gdW5sZXNzIHRoZXkgYXJlIGdpdmVu KS4KKyAgICAvLyBJZiB2YWxpZCBmaWxlIG1ldGFkYXRhICh3aG9zZSBsZW5ndGggZmllbGQgaXMg bm9uLW5lZ2F0aXZlKSBpcyBnaXZlbiBhdCBjb25zdHJ1Y3Rpb24gdGltZSB3ZSB1c2UgdGhlIG1l dGFkYXRhIGluIHNpemUoKSwgbGFzdE1vZGlmaWVkVGltZSgpIGFuZCB3ZWJraXRTbGljZSgpLgor ICAgIC8vIEJ5IGRlZmF1bHQgd2UgaW5pdGlhbGl6ZSBtX3NuYXBzaG90U2l6ZSB0byAtMSBzbyB0 aGF0IHdlIGRvbid0IHVzZSB0aGVzZSBtZXRhZGF0YSB1bmxlc3MgaXQgaXMgZ2l2ZW4uCisgICAg Ly8gTm90ZSB0aGF0IHdlIG1heSByZXR1cm4gbnVsbCBsYXN0TW9kaWZpZWRUaW1lIGlmIGl0IGlz IGdpdmVuICh0b2dldGhlciB3aXRoIHBvc2l0aXZlIGZpbGUgbGVuZ3RoKS4KICAgICBjb25zdCBs b25nIGxvbmcgbV9zbmFwc2hvdFNpemU7CiAgICAgY29uc3QgZG91YmxlIG1fc25hcHNob3RNb2Rp ZmljYXRpb25UaW1lOwogI2VuZGlmCg== 143720 2012-05-23 21:04:18 -0700 2012-05-28 07:11:32 -0700 Patch bug-86811-20120524130417.patch text/plain 3894 kinuko U3VidmVyc2lvbiBSZXZpc2lvbjogMTE3NDU2CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggYjRjMmEzM2ZkZGM1MmJi N2YzMDdkNGYzMDkyNWU1Y2MwODk2ZTQxMS4uNWYwZjVmODgyYTNlNmIzOTcwNzJkMjgwMjE5OTFj NGJlMTUzMzgwZCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIwIEBACisyMDEyLTA1LTIzICBLaW51 a28gWWFzdWRhICA8a2ludWtvQGNocm9taXVtLm9yZz4KKworICAgICAgICBSRUdSRVNTSU9OOiBX ZSBzaG91bGQgYWxsb3cgbnVsbCBtb2RpZmljYXRpb25UaW1lIHdoZW4gc25hcHNob3QgbWV0YWRh dGEgaXMgZ2l2ZW4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTg2ODExCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAg ICAgTm8gbmV3IHRlc3RzIGFzIHRoaXMgY2hhbmdlIGlzIG5vdCBmb3IgcmVndWxhciBmaWxlcy9m aWxlc3lzdGVtcy4KKyAgICAgICAgKFRlc3RzIGluIENocm9tZSBPUyBwb3J0IHNob3VsZCBiZSBh YmxlIHRvIHZlcmlmeSB0aGlzKQorCisgICAgICAgICogZmlsZWFwaS9GaWxlLmNwcDoKKyAgICAg ICAgKFdlYkNvcmU6OkZpbGU6Omxhc3RNb2RpZmllZERhdGUpOgorICAgICAgICAoV2ViQ29yZTo6 RmlsZTo6c2l6ZSk6CisgICAgICAgIChXZWJDb3JlOjpGaWxlOjpjYXB0dXJlU25hcHNob3QpOgor ICAgICAgICAqIGZpbGVhcGkvRmlsZS5oOgorICAgICAgICAoRmlsZSk6CisKIDIwMTItMDUtMTcg IFBhdmVsIEZlbGRtYW4gIDxwZmVsZG1hbkBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgV2ViIElu c3BlY3RvcjogY3JlYXRlIFNvdXJjZUZyYW1lcyB3aXRoIGNvbnRlbnQgcHJvdmlkZXJzLgpkaWZm IC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmNwcCBiL1NvdXJjZS9XZWJDb3Jl L2ZpbGVhcGkvRmlsZS5jcHAKaW5kZXggZjJhZmEzNDU0YTBjZDMzY2Y2MTdjNDA0Nzk2OGVhZTk5 N2MwZWQxNC4uZGUyMWFhNTMxMTNmYzY3MTBlN2VlZmFkYmFkMTg1MDlkMzE4MmE1NiAxMDA2NDQK LS0tIGEvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmNwcAorKysgYi9Tb3VyY2UvV2ViQ29y ZS9maWxlYXBpL0ZpbGUuY3BwCkBAIC0xMzAsNyArMTMwLDcgQEAgRmlsZTo6RmlsZShjb25zdCBT dHJpbmcmIG5hbWUsIGNvbnN0IEZpbGVNZXRhZGF0YSYgbWV0YWRhdGEpCiBkb3VibGUgRmlsZTo6 bGFzdE1vZGlmaWVkRGF0ZSgpIGNvbnN0CiB7CiAjaWYgRU5BQkxFKEZJTEVfU1lTVEVNKQotICAg IGlmIChtX3NuYXBzaG90U2l6ZSA+PSAwICYmIG1fc25hcHNob3RNb2RpZmljYXRpb25UaW1lKQor ICAgIGlmIChtX3NuYXBzaG90U2l6ZSA+PSAwKQogICAgICAgICByZXR1cm4gbV9zbmFwc2hvdE1v ZGlmaWNhdGlvblRpbWUgKiAxMDAwLjA7CiAjZW5kaWYKIApAQCAtMTQ1LDcgKzE0NSw3IEBAIGRv dWJsZSBGaWxlOjpsYXN0TW9kaWZpZWREYXRlKCkgY29uc3QKIHVuc2lnbmVkIGxvbmcgbG9uZyBG aWxlOjpzaXplKCkgY29uc3QKIHsKICNpZiBFTkFCTEUoRklMRV9TWVNURU0pCi0gICAgaWYgKG1f c25hcHNob3RTaXplID49IDAgJiYgbV9zbmFwc2hvdE1vZGlmaWNhdGlvblRpbWUpCisgICAgaWYg KG1fc25hcHNob3RTaXplID49IDApCiAgICAgICAgIHJldHVybiBtX3NuYXBzaG90U2l6ZTsKICNl bmRpZgogCkBAIC0xNjAsNyArMTYwLDcgQEAgdW5zaWduZWQgbG9uZyBsb25nIEZpbGU6OnNpemUo KSBjb25zdAogdm9pZCBGaWxlOjpjYXB0dXJlU25hcHNob3QobG9uZyBsb25nJiBzbmFwc2hvdFNp emUsIGRvdWJsZSYgc25hcHNob3RNb2RpZmljYXRpb25UaW1lKSBjb25zdAogewogI2lmIEVOQUJM RShGSUxFX1NZU1RFTSkKLSAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCAmJiBtX3NuYXBzaG90 TW9kaWZpY2F0aW9uVGltZSkgeworICAgIGlmIChtX3NuYXBzaG90U2l6ZSA+PSAwKSB7CiAgICAg ICAgIHNuYXBzaG90U2l6ZSA9IG1fc25hcHNob3RTaXplOwogICAgICAgICBzbmFwc2hvdE1vZGlm aWNhdGlvblRpbWUgPSBtX3NuYXBzaG90TW9kaWZpY2F0aW9uVGltZTsKICAgICAgICAgcmV0dXJu OwpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmggYi9Tb3VyY2UvV2Vi Q29yZS9maWxlYXBpL0ZpbGUuaAppbmRleCA2MzMxYTJkNDk5NzY3MmI2ZmYxYjRkNjY2ZWFmNDdk YzUwOTk1ZDAzLi5hMGVhYmExZDg2NjgzNTY5NjM3ZTRhMWE5YzA1NzUyZjU5ZTk3ZGZiIDEwMDY0 NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9maWxlYXBpL0ZpbGUuaAorKysgYi9Tb3VyY2UvV2ViQ29y ZS9maWxlYXBpL0ZpbGUuaApAQCAtNTQsNyArNTQsNyBAQCBwdWJsaWM6CiAjZW5kaWYKIAogI2lm IEVOQUJMRShGSUxFX1NZU1RFTSkKLSAgICAvLyBJZiBmaWxlc3lzdGVtIGZpbGVzIGxpdmUgaW4g dGhlIHJlbW90ZSBmaWxlc3lzdGVtLCB0aGUgcG9ydCBtaWdodCBwYXNzIHRoZSB2YWxpZCBtZXRh ZGF0YSAobm9uLXplcm8gbW9kaWZpY2F0aW9uVGltZSBhbmQgbm9uLW5lZ2F0aXZlIGZpbGUgc2l6 ZSkgYW5kIGNhY2hlIGluIHRoZSBGaWxlIG9iamVjdC4KKyAgICAvLyBJZiBmaWxlc3lzdGVtIGZp bGVzIGxpdmUgaW4gdGhlIHJlbW90ZSBmaWxlc3lzdGVtLCB0aGUgcG9ydCBtaWdodCBwYXNzIHRo ZSB2YWxpZCBtZXRhZGF0YSAod2hvc2UgbGVuZ3RoIGZpZWxkIGlzIG5vbi1uZWdhdGl2ZSkgYW5k IGNhY2hlIGluIHRoZSBGaWxlIG9iamVjdC4KICAgICAvLwogICAgIC8vIE90aGVyd2lzZSBjYWxs aW5nIHNpemUoKSwgbGFzdE1vZGlmaWVkVGltZSgpIGFuZCB3ZWJraXRTbGljZSgpIHdpbGwgc3lu Y2hyb25vdXNseSBxdWVyeSB0aGUgZmlsZSBtZXRhZGF0YS4KICAgICBzdGF0aWMgUGFzc1JlZlB0 cjxGaWxlPiBjcmVhdGVGb3JGaWxlU3lzdGVtRmlsZShjb25zdCBTdHJpbmcmIG5hbWUsIGNvbnN0 IEZpbGVNZXRhZGF0YSYgbWV0YWRhdGEpCkBAIC0xMDAsOCArMTAwLDkgQEAgcHJpdmF0ZToKICAg ICBTdHJpbmcgbV9uYW1lOwogCiAjaWYgRU5BQkxFKEZJTEVfU1lTVEVNKQotICAgIC8vIElmIG5v bi16ZXJvIG1vZGlmaWNhdGlvblRpbWUgYW5kIG5vbi1uZWdhdGl2ZSBmaWxlIHNpemUgYXJlIGdp dmVuIGF0IGNvbnN0cnVjdGlvbiB0aW1lIHdlIHVzZSB0aGVtIGluIHNpemUoKSwgbGFzdE1vZGlm aWVkVGltZSgpIGFuZCB3ZWJraXRTbGljZSgpLgotICAgIC8vIEJ5IGRlZmF1bHQgd2UgaW5pdGlh bGl6ZSBtX3NuYXBzaG90U2l6ZSB0byAtMSBhbmQgbV9zbmFwc2hvdE1vZGlmaWNhdGlvblRpbWUg dG8gMCAoc28gdGhhdCB3ZSBkb24ndCB1c2UgdGhlbSB1bmxlc3MgdGhleSBhcmUgZ2l2ZW4pLgor ICAgIC8vIElmIHZhbGlkIGZpbGUgbWV0YWRhdGEgKHdob3NlIGxlbmd0aCBmaWVsZCBpcyBub24t bmVnYXRpdmUpIGlzIGdpdmVuIGF0IGNvbnN0cnVjdGlvbiB0aW1lIHdlIHVzZSB0aGUgbWV0YWRh dGEgaW4gc2l6ZSgpLCBsYXN0TW9kaWZpZWRUaW1lKCkgYW5kIHdlYmtpdFNsaWNlKCkuCisgICAg Ly8gQnkgZGVmYXVsdCB3ZSBpbml0aWFsaXplIG1fc25hcHNob3RTaXplIHRvIC0xIHNvIHRoYXQg d2UgZG9uJ3QgdXNlIHRoZXNlIG1ldGFkYXRhIHVubGVzcyBpdCBpcyBnaXZlbi4KKyAgICAvLyBO b3RlIHRoYXQgd2UgbWF5IHJldHVybiBudWxsIGxhc3RNb2RpZmllZFRpbWUgaWYgaXQgaXMgZ2l2 ZW4gKHRvZ2V0aGVyIHdpdGggcG9zaXRpdmUgZmlsZSBsZW5ndGgpLgogICAgIGNvbnN0IGxvbmcg bG9uZyBtX3NuYXBzaG90U2l6ZTsKICAgICBjb25zdCBkb3VibGUgbV9zbmFwc2hvdE1vZGlmaWNh dGlvblRpbWU7CiAjZW5kaWYK 144354 2012-05-28 07:11:02 -0700 2012-05-29 09:59:04 -0700 Patch bug-86811-20120528231100.patch text/plain 6074 kinuko U3VidmVyc2lvbiBSZXZpc2lvbjogMTE4NTYwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggMzRiNTAyNjEwMWFkNzc2 NzlmNjgwOGM0NzgyODc4ODZjYjIzNWMwMi4uMWRmOWI1ZDAxNzhkZjgyMDlkZWZlNmQ2ZDk4Yzk2 ZmQ2NDdlYTg5MCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDM0IEBACisyMDEyLTA1LTIzICBLaW51 a28gWWFzdWRhICA8a2ludWtvQGNocm9taXVtLm9yZz4KKworICAgICAgICBSRUdSRVNTSU9OOiBX ZSBzaG91bGQgYWxsb3cgbnVsbCBtb2RpZmljYXRpb25UaW1lIHdoZW4gc25hcHNob3QgbWV0YWRh dGEgaXMgZ2l2ZW4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTg2ODExCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAg ICAgcjExNzQzMiBoYXMgaW50cm9kdWNlZCBhIG5ldyBGaWxlIGNvbnN0cnVjdG9yIHdoaWNoIGFs bG93cyB0aGUgY2FsbGVyCisgICAgICAgIHRvIHBhc3MgaW4gYSBzbmFwc2hvdCBmaWxlIG1ldGFk YXRhLiBJbiB0aGUgY2hhbmdlIHdlIGhhZCBjb25zaWRlcmVkIHRoZQorICAgICAgICBnaXZlbiBt ZXRhZGF0YSBpcyB2YWxpZCBpZiAibWV0YWRhdGEubGVuZ3RoID49IDAgQU5EIG1ldGFkYXRhLmxh c3RNb2RpZmllZERhdGUgIT0gMCIsCisgICAgICAgIGJ1dCB3ZSBzaG91bGQgZHJvcCB0aGUgbGF0 dGVyIGNvbmRpdGlvbiAobGFzdE1vZGlmaWVkRGF0ZSAhPSAwKSBiZWNhdXNlCisKKyAgICAgICAg MS4gdGhlIHZhbHVlIDAgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGUgdGltZSBpbmZvcm1hdGlvbiBp cyB1bmF2YWlsYWJsZSBpbiBGaWxlLCBhbmQKKyAgICAgICAgMi4gaXQgaXMgdmFsaWQgcGVyIHNw ZWMgd2hldGhlciBpdCBpbmRpY2F0ZXMoaHR0cDovL2Rldi53My5vcmcvMjAwNi93ZWJhcGkvRmls ZUFQSS8jZGZuLWxhc3RNb2RpZmllZERhdGUgc2F5cyB0aGUKKyAgICAgICAgVUEgbXVzdCByZXR1 cm4gbnVsbCBpZiB0aGUgaW5mb3JtYXRpb24gaXMgbm90IGF2YWlsYWJsZSkuCisKKyAgICAgICAg KE5vdGU6IHRoZSBjdXJyZW50IGpzL3Y4IGJpbmRpbmcgcmV0dXJucyBEYXRlKDApIGZvciB0aGUg dGltZSB2YWx1ZSAwLAorICAgICAgICB3aGljaCBpcyBzdGlsbCB2YWxpZCBhcyBlcG9jaCB0aW1l IGJ1dCB3b3VsZCBmYWlsIHRvIGluZGljYXRlIHRoZQorICAgICAgICB1bmF2YWlsYWJpbGl0eSBv ZiB0aGUgaW5mb3JtYXRpb24uIEluIHRoaXMgcGF0Y2ggSSBhZGRlZCBGSVhNRSBpbgorICAgICAg ICBGaWxlLmlkbCBidXQgd2lsbCBmaXggaW4gYW5vdGhlciBwYXRjaC4pCisKKyAgICAgICAgTm8g bmV3IHRlc3RzIGFzIHRoaXMgY2hhbmdlIGRvZXMgbm90IGFmZmVjdCByZWd1bGFyIGZpbGVzL2Zp bGVzeXN0ZW1zIGJlaGF2aW9yLgorICAgICAgICAoVGVzdHMgaW4gQ2hyb21lIE9TIHBvcnQgc2hv dWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRoaXMpCisKKyAgICAgICAgKiBmaWxlYXBpL0ZpbGUuY3Bw OgorICAgICAgICAoV2ViQ29yZTo6RmlsZTo6bGFzdE1vZGlmaWVkRGF0ZSk6CisgICAgICAgIChX ZWJDb3JlOjpGaWxlOjpzaXplKToKKyAgICAgICAgKFdlYkNvcmU6OkZpbGU6OmNhcHR1cmVTbmFw c2hvdCk6CisgICAgICAgICogZmlsZWFwaS9GaWxlLmg6CisgICAgICAgIChGaWxlKToKKwogMjAx Mi0wNS0yNSAgRGVhbiBKYWNrc29uICA8ZGlub0BhcHBsZS5jb20+CiAKICAgICAgICAgVW5yZXZp ZXdlZCwgcm9sbGluZyBvdXQgcjExMjE1NS4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2Zp bGVhcGkvRmlsZS5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9maWxlYXBpL0ZpbGUuY3BwCmluZGV4IDA5 ODA4NDgwN2QwYmEyY2NlMDJjMjM0MzdjOTgwNzZmMWFkYTJhMjYuLjU0YWVjNTFhNzZiNzA1NmRh NTMzMmE5Nzk2ZWM1MjY0ZjIzMTBiZjMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2ZpbGVh cGkvRmlsZS5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmNwcApAQCAtMTMw LDcgKzEzMCw3IEBAIEZpbGU6OkZpbGUoY29uc3QgU3RyaW5nJiBuYW1lLCBjb25zdCBGaWxlTWV0 YWRhdGEmIG1ldGFkYXRhKQogZG91YmxlIEZpbGU6Omxhc3RNb2RpZmllZERhdGUoKSBjb25zdAog ewogI2lmIEVOQUJMRShGSUxFX1NZU1RFTSkKLSAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCAm JiBtX3NuYXBzaG90TW9kaWZpY2F0aW9uVGltZSkKKyAgICBpZiAoaGFzVmFsaWRTbmFwc2hvdE1l dGFkYXRhKCkpCiAgICAgICAgIHJldHVybiBtX3NuYXBzaG90TW9kaWZpY2F0aW9uVGltZSAqIDEw MDAuMDsKICNlbmRpZgogCkBAIC0xNDUsNyArMTQ1LDcgQEAgZG91YmxlIEZpbGU6Omxhc3RNb2Rp ZmllZERhdGUoKSBjb25zdAogdW5zaWduZWQgbG9uZyBsb25nIEZpbGU6OnNpemUoKSBjb25zdAog ewogI2lmIEVOQUJMRShGSUxFX1NZU1RFTSkKLSAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCAm JiBtX3NuYXBzaG90TW9kaWZpY2F0aW9uVGltZSkKKyAgICBpZiAoaGFzVmFsaWRTbmFwc2hvdE1l dGFkYXRhKCkpCiAgICAgICAgIHJldHVybiBtX3NuYXBzaG90U2l6ZTsKICNlbmRpZgogCkBAIC0x NjAsNyArMTYwLDcgQEAgdW5zaWduZWQgbG9uZyBsb25nIEZpbGU6OnNpemUoKSBjb25zdAogdm9p ZCBGaWxlOjpjYXB0dXJlU25hcHNob3QobG9uZyBsb25nJiBzbmFwc2hvdFNpemUsIGRvdWJsZSYg c25hcHNob3RNb2RpZmljYXRpb25UaW1lKSBjb25zdAogewogI2lmIEVOQUJMRShGSUxFX1NZU1RF TSkKLSAgICBpZiAobV9zbmFwc2hvdFNpemUgPj0gMCAmJiBtX3NuYXBzaG90TW9kaWZpY2F0aW9u VGltZSkgeworICAgIGlmIChoYXNWYWxpZFNuYXBzaG90TWV0YWRhdGEoKSkgewogICAgICAgICBz bmFwc2hvdFNpemUgPSBtX3NuYXBzaG90U2l6ZTsKICAgICAgICAgc25hcHNob3RNb2RpZmljYXRp b25UaW1lID0gbV9zbmFwc2hvdE1vZGlmaWNhdGlvblRpbWU7CiAgICAgICAgIHJldHVybjsKZGlm ZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5oIGIvU291cmNlL1dlYkNvcmUv ZmlsZWFwaS9GaWxlLmgKaW5kZXggZTg1MmM2YWRmNjdjYzdiZDkwNDY1ZTFjMzI2ZTI4MTkxYTkx MTNjYy4uOGJjNDgwZDJjNDJkMjg2OWIyZmRiOGQ1Zjk2NTM4MzBkYzNhZTIxYiAxMDA2NDQKLS0t IGEvU291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmgKKysrIGIvU291cmNlL1dlYkNvcmUvZmls ZWFwaS9GaWxlLmgKQEAgLTU0LDcgKzU0LDcgQEAgcHVibGljOgogI2VuZGlmCiAKICNpZiBFTkFC TEUoRklMRV9TWVNURU0pCi0gICAgLy8gSWYgZmlsZXN5c3RlbSBmaWxlcyBsaXZlIGluIHRoZSBy ZW1vdGUgZmlsZXN5c3RlbSwgdGhlIHBvcnQgbWlnaHQgcGFzcyB0aGUgdmFsaWQgbWV0YWRhdGEg KG5vbi16ZXJvIG1vZGlmaWNhdGlvblRpbWUgYW5kIG5vbi1uZWdhdGl2ZSBmaWxlIHNpemUpIGFu ZCBjYWNoZSBpbiB0aGUgRmlsZSBvYmplY3QuCisgICAgLy8gSWYgZmlsZXN5c3RlbSBmaWxlcyBs aXZlIGluIHRoZSByZW1vdGUgZmlsZXN5c3RlbSwgdGhlIHBvcnQgbWlnaHQgcGFzcyB0aGUgdmFs aWQgbWV0YWRhdGEgKHdob3NlIGxlbmd0aCBmaWVsZCBpcyBub24tbmVnYXRpdmUpIGFuZCBjYWNo ZSBpbiB0aGUgRmlsZSBvYmplY3QuCiAgICAgLy8KICAgICAvLyBPdGhlcndpc2UgY2FsbGluZyBz aXplKCksIGxhc3RNb2RpZmllZFRpbWUoKSBhbmQgd2Via2l0U2xpY2UoKSB3aWxsIHN5bmNocm9u b3VzbHkgcXVlcnkgdGhlIGZpbGUgbWV0YWRhdGEuCiAgICAgc3RhdGljIFBhc3NSZWZQdHI8Rmls ZT4gY3JlYXRlRm9yRmlsZVN5c3RlbUZpbGUoY29uc3QgU3RyaW5nJiBuYW1lLCBjb25zdCBGaWxl TWV0YWRhdGEmIG1ldGFkYXRhKQpAQCAtNzYsNyArNzYsMTAgQEAgcHVibGljOgogCiAgICAgY29u c3QgU3RyaW5nJiBwYXRoKCkgY29uc3QgeyByZXR1cm4gbV9wYXRoOyB9CiAgICAgY29uc3QgU3Ry aW5nJiBuYW1lKCkgY29uc3QgeyByZXR1cm4gbV9uYW1lOyB9CisKKyAgICAvLyBUaGlzIG1heSBy ZXR1cm4gemVybyBpZiBnZXRGaWxlTW9kaWZpY2F0aW9uVGltZSgpIHBsYXRmb3JtIGNhbGwgaGFz IGZhaWxlZCBvciB6ZXJvIHNuYXBzaG90IGxhc3RNb2RpZmllZFRpbWUgaXMgZ2l2ZW4gYXQgY29u c3RydWN0aW9uIHRpbWUuCiAgICAgZG91YmxlIGxhc3RNb2RpZmllZERhdGUoKSBjb25zdDsKKwog I2lmIEVOQUJMRShESVJFQ1RPUllfVVBMT0FEKQogICAgIC8vIFJldHVybnMgdGhlIHJlbGF0aXZl IHBhdGggb2YgdGhpcyBmaWxlIGluIHRoZSBjb250ZXh0IG9mIGEgZGlyZWN0b3J5IHNlbGVjdGlv bi4KICAgICBjb25zdCBTdHJpbmcmIHdlYmtpdFJlbGF0aXZlUGF0aCgpIGNvbnN0IHsgcmV0dXJu IG1fcmVsYXRpdmVQYXRoOyB9CkBAIC05NCwxNCArOTcsMTcgQEAgcHJpdmF0ZToKIAogIyBpZiBF TkFCTEUoRklMRV9TWVNURU0pCiAgICAgRmlsZShjb25zdCBTdHJpbmcmIG5hbWUsIGNvbnN0IEZp bGVNZXRhZGF0YSYpOworCisgICAgLy8gUmV0dXJucyB0cnVlIGlmIHRoaXMgaGFzIGEgdmFsaWQg c25hcHNob3QgbWV0YWRhdGEgKGkuZS4gbV9zbmFwc2hvdFNpemUgPj0gMCkuCisgICAgYm9vbCBo YXNWYWxpZFNuYXBzaG90TWV0YWRhdGEoKSBjb25zdCB7IHJldHVybiBtX3NuYXBzaG90U2l6ZSA+ PSAwOyB9CiAjZW5kaWYKIAogICAgIFN0cmluZyBtX3BhdGg7CiAgICAgU3RyaW5nIG1fbmFtZTsK IAogI2lmIEVOQUJMRShGSUxFX1NZU1RFTSkKLSAgICAvLyBJZiBub24temVybyBtb2RpZmljYXRp b25UaW1lIGFuZCBub24tbmVnYXRpdmUgZmlsZSBzaXplIGFyZSBnaXZlbiBhdCBjb25zdHJ1Y3Rp b24gdGltZSB3ZSB1c2UgdGhlbSBpbiBzaXplKCksIGxhc3RNb2RpZmllZFRpbWUoKSBhbmQgd2Vi a2l0U2xpY2UoKS4KLSAgICAvLyBCeSBkZWZhdWx0IHdlIGluaXRpYWxpemUgbV9zbmFwc2hvdFNp emUgdG8gLTEgYW5kIG1fc25hcHNob3RNb2RpZmljYXRpb25UaW1lIHRvIDAgKHNvIHRoYXQgd2Ug ZG9uJ3QgdXNlIHRoZW0gdW5sZXNzIHRoZXkgYXJlIGdpdmVuKS4KKyAgICAvLyBJZiBtX3NuYXBz aG90U2l6ZSBpcyBuZWdhdGl2ZSAoaW5pdGlhbGl6ZWQgdG8gLTEgYnkgZGVmYXVsdCksIHRoZSBz bmFwc2hvdCBtZXRhZGF0YSBpcyBpbnZhbGlkIGFuZCB3ZSByZXRyaWV2ZSB0aGUgbGF0ZXN0IG1l dGFkYXRhIHN5bmNocm9ub3VzbHkgaW4gc2l6ZSgpLCBsYXN0TW9kaWZpZWRUaW1lKCkgYW5kIHdl YmtpdFNsaWNlKCkuCisgICAgLy8gT3RoZXJ3aXNlLCB0aGUgc25hcHNob3QgbWV0YWRhdGEgYXJl IHVzZWQgZGlyZWN0bHkgaW4gdGhvc2UgbWV0aG9kcy4KICAgICBjb25zdCBsb25nIGxvbmcgbV9z bmFwc2hvdFNpemU7CiAgICAgY29uc3QgZG91YmxlIG1fc25hcHNob3RNb2RpZmljYXRpb25UaW1l OwogI2VuZGlmCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9maWxlYXBpL0ZpbGUuaWRsIGIv U291cmNlL1dlYkNvcmUvZmlsZWFwaS9GaWxlLmlkbAppbmRleCA3YzBkZTQzMDlkZmRhNWE2MGVk MTQzY2FhNTQ4YjM1OTk0MTI4ZDVlLi5lODhiOWJmZWE0ZmFiYTRkNTdhZDIzMTBiZmY1ZTZmMzkz YmNmYzgxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9maWxlYXBpL0ZpbGUuaWRsCisrKyBi L1NvdXJjZS9XZWJDb3JlL2ZpbGVhcGkvRmlsZS5pZGwKQEAgLTMyLDYgKzMyLDcgQEAgbW9kdWxl IGh0bWwgewogICAgIF0gRmlsZSA6IEJsb2IgewogICAgICAgICByZWFkb25seSBhdHRyaWJ1dGUg RE9NU3RyaW5nIG5hbWU7CiAjaWYgIWRlZmluZWQoTEFOR1VBR0VfR09CSkVDVCkgfHwgIUxBTkdV QUdFX0dPQkpFQ1QKKyAgICAgICAgLy8gRklYTUU6IHRoaXMgc2hvdWxkIHJldHVybiBudWxsIERh dGUgaWYgdGhlIHZhbHVlIGlzIDAuCiAgICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBEYXRlIGxh c3RNb2RpZmllZERhdGU7CiAjZW5kaWYKICNpZiBkZWZpbmVkKEVOQUJMRV9ESVJFQ1RPUllfVVBM T0FEKSAmJiBFTkFCTEVfRElSRUNUT1JZX1VQTE9BRAo=