219838 2020-12-13 11:52:45 -0800 Web process crashes during MotionMark Images when GPU Process for DOM is enabled 2020-12-14 10:04:19 -0800 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 wenson_hsieh wenson_hsieh sabouhallawa sam simon.fraser thorton webkit-bug-importer oldest_to_newest 1714336 0 wenson_hsieh 2020-12-13 11:52:45 -0800 Another crash due to backend creation failure: Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [2237] Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 WebKit 0x000000010352857c WebKit::ImageBufferShareableIOSurfaceBackend::createImageBufferBackendHandle() const + 24 1 WebKit 0x0000000103206474 WebKit::RemoteLayerBackingStore::encode(IPC::Encoder&) const + 316 2 WebKit 0x0000000103206474 WebKit::RemoteLayerBackingStore::encode(IPC::Encoder&) const + 316 3 WebKit 0x000000010320a050 WebKit::RemoteLayerTreeTransaction::LayerProperties::encode(IPC::Encoder&) const + 1184 4 WebKit 0x000000010320ac84 WebKit::RemoteLayerTreeTransaction::encode(IPC::Encoder&) const + 164 5 WebKit 0x000000010308fee4 WebKit::RemoteLayerTreeDrawingArea::updateRendering() + 552 6 WebCore 0x00000001091d42e4 WebCore::ThreadTimers::sharedTimerFiredInternal() + 224 7 WebCore 0x00000001091faa34 WebCore::timerFired(__CFRunLoopTimer*, void*) + 32 8 CoreFoundation 0x00000001a782734c __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 9 CoreFoundation 0x00000001a7826f48 __CFRunLoopDoTimer + 1076 10 CoreFoundation 0x00000001a7826398 __CFRunLoopDoTimers + 328 11 CoreFoundation 0x00000001a782014c __CFRunLoopRun + 1944 12 CoreFoundation 0x00000001a781f480 CFRunLoopRunSpecific + 600 13 Foundation 0x00000001a8ceccac -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 232 14 Foundation 0x00000001a8d203b8 -[NSRunLoop(NSRunLoop) run] + 92 15 libxpc.dylib 0x00000001f560e2cc _xpc_objc_main + 688 16 libxpc.dylib 0x00000001f56105e8 xpc_main + 180 17 WebKit 0x00000001031ce0b4 WebKit::XPCServiceMain(int, char const**) + 124 18 libdyld.dylib 0x00000001a74dd38c start + 4 1714338 1 416124 wenson_hsieh 2020-12-13 12:09:00 -0800 Created attachment 416124 Patch 1714348 2 416124 sam 2020-12-13 15:31:45 -0800 Comment on attachment 416124 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416124&action=review > Source/WebKit/ChangeLog:21 > + B subsequently finishes waiting for backend creation because it incorrectly believes that its backend has been > + initialized, and we end up crashing downstream in `RemoteLayerBackingStore::encode()` because > + `ensureBackendCreated()` for B returned null. Seems like we will still have this issue, just perhaps less often, since we will still return null from ensureBackendCreated() if enough callers call ensureBackendCreated() at the same time, or am I missing something? > Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h:140 > + static constexpr unsigned maximumNumberOfTimeouts = 3; > + unsigned numberOfTimeouts = 0; > + while (!m_backend && numberOfTimeouts < maximumNumberOfTimeouts) { > + if (!m_remoteRenderingBackendProxy->waitForDidCreateImageBufferBackend()) > + ++numberOfTimeouts; > + } It seems a bit odd to call these timeouts if they also represent other sync messages that have been delivered in the interim (which is what I think you are saying they do). Can we differentiate between actual timeouts and other things that would cause waitForDidCreateImageBufferBackend to return prematurely? 1714354 3 416124 wenson_hsieh 2020-12-13 15:50:20 -0800 Comment on attachment 416124 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=416124&action=review >> Source/WebKit/ChangeLog:21 >> + `ensureBackendCreated()` for B returned null. > > Seems like we will still have this issue, just perhaps less often, since we will still return null from ensureBackendCreated() if enough callers call ensureBackendCreated() at the same time, or am I missing something? After this change, we'll only return null here if we time out 3 times. As explained in the changelog entry below, we only increment the counter upon IPC timeout (or any other kind of IPC communication failure). So if we receive, say, 10 `RemoteRenderingBackendProxy::DidCreateImageBufferBackend` responses where the 10th response confirms our RemoteImageBufferProxy, we'll spin in the while loop a total of 10 times and then return successfully. However, if the GPU process, say, hits an infinite loop, we'll subsequently loop 3 times here and then give up and return null. I think I also want to refactor `ensureBackendCreated` so that it doesn't have a max timeout limit and instead returns an `ImageBufferBackend&`, but I was planning to do that separately. >> Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h:140 >> + } > > It seems a bit odd to call these timeouts if they also represent other sync messages that have been delivered in the interim (which is what I think you are saying they do). Can we differentiate between actual timeouts and other things that would cause waitForDidCreateImageBufferBackend to return prematurely? Hm…is this addressed by my comment above? 1714355 4 wenson_hsieh 2020-12-13 15:57:41 -0800 (In reply to Sam Weinig from comment #2) > Comment on attachment 416124 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=416124&action=review > > > Source/WebKit/ChangeLog:21 > > + B subsequently finishes waiting for backend creation because it incorrectly believes that its backend has been > > + initialized, and we end up crashing downstream in `RemoteLayerBackingStore::encode()` because > > + `ensureBackendCreated()` for B returned null. > > Seems like we will still have this issue, just perhaps less often, since we > will still return null from ensureBackendCreated() if enough callers call > ensureBackendCreated() at the same time, or am I missing something? I should also clarify — the DidCreateImageBufferBackend message is both sent by the GPU process asynchronously and received by the web process asynchronously. We only hit this sync codepath in the web process (ensureBackendCreated) in the case where we definitely require the backend to have been created in the web process. Since all callers of `ensureBackendCreated()` are on the main thread, there should only ever be one caller of `ensureBackendCreated()` at a time in the web process — the issue is that there could be multiple `DidCreateImageBufferBackend` messages that have been dispatched by the GPU process, and are waiting to be handled in the web process at the point where we call `ensureBackendCreated()`. > > > Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h:140 > > + static constexpr unsigned maximumNumberOfTimeouts = 3; > > + unsigned numberOfTimeouts = 0; > > + while (!m_backend && numberOfTimeouts < maximumNumberOfTimeouts) { > > + if (!m_remoteRenderingBackendProxy->waitForDidCreateImageBufferBackend()) > > + ++numberOfTimeouts; > > + } > > It seems a bit odd to call these timeouts if they also represent other sync > messages that have been delivered in the interim (which is what I think you > are saying they do). Can we differentiate between actual timeouts and other > things that would cause waitForDidCreateImageBufferBackend to return > prematurely? 1714362 5 sam 2020-12-13 18:27:16 -0800 (In reply to Wenson Hsieh from comment #3) > Comment on attachment 416124 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=416124&action=review > > >> Source/WebKit/ChangeLog:21 > >> + `ensureBackendCreated()` for B returned null. > > > > Seems like we will still have this issue, just perhaps less often, since we will still return null from ensureBackendCreated() if enough callers call ensureBackendCreated() at the same time, or am I missing something? > > After this change, we'll only return null here if we time out 3 times. As > explained in the changelog entry below, we only increment the counter upon > IPC timeout (or any other kind of IPC communication failure). > > So if we receive, say, 10 > `RemoteRenderingBackendProxy::DidCreateImageBufferBackend` responses where > the 10th response confirms our RemoteImageBufferProxy, we'll spin in the > while loop a total of 10 times and then return successfully. However, if the > GPU process, say, hits an infinite loop, we'll subsequently loop 3 times > here and then give up and return null. I'm having trouble following the logic in the code, but I think I get it. If RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns true, which happens when a sync message is received (and not a timeout) we just loop. I think the real issue I am having is that the function RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns a bool and gives no indication what that bool means (thought this seems to extend down in Connection::waitForAndDispatchImmediately as well). Ideally we would only return bools from functions that were clearly predicates. Can we change RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() to return an enum to make it make it clear what it is saying. Otherwise, this code is just mysterious. 1714363 6 wenson_hsieh 2020-12-13 18:40:38 -0800 (In reply to Sam Weinig from comment #5) > (In reply to Wenson Hsieh from comment #3) > > Comment on attachment 416124 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=416124&action=review > > > > >> Source/WebKit/ChangeLog:21 > > >> + `ensureBackendCreated()` for B returned null. > > > > > > Seems like we will still have this issue, just perhaps less often, since we will still return null from ensureBackendCreated() if enough callers call ensureBackendCreated() at the same time, or am I missing something? > > > > After this change, we'll only return null here if we time out 3 times. As > > explained in the changelog entry below, we only increment the counter upon > > IPC timeout (or any other kind of IPC communication failure). > > > > So if we receive, say, 10 > > `RemoteRenderingBackendProxy::DidCreateImageBufferBackend` responses where > > the 10th response confirms our RemoteImageBufferProxy, we'll spin in the > > while loop a total of 10 times and then return successfully. However, if the > > GPU process, say, hits an infinite loop, we'll subsequently loop 3 times > > here and then give up and return null. > > I'm having trouble following the logic in the code, but I think I get it. If > RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns > true, which happens when a sync message is received (and not a timeout) we > just loop. Ah, yes — this was indeed the key bit. > > I think the real issue I am having is that the function > RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns a > bool and gives no indication what that bool means (thought this seems to > extend down in Connection::waitForAndDispatchImmediately as well). Ideally > we would only return bools from functions that were clearly predicates. Can > we change RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() > to return an enum to make it make it clear what it is saying. Otherwise, > this code is just mysterious. Yep, that sounds good! Will change this to return something along the lines of: enum class DidReceiveBackendCreationMessage : bool { No, Yes }; 1714367 7 sam 2020-12-13 20:01:12 -0800 (In reply to Wenson Hsieh from comment #6) > (In reply to Sam Weinig from comment #5) > > (In reply to Wenson Hsieh from comment #3) > > > Comment on attachment 416124 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=416124&action=review > > > > > > >> Source/WebKit/ChangeLog:21 > > > >> + `ensureBackendCreated()` for B returned null. > > > > > > > > Seems like we will still have this issue, just perhaps less often, since we will still return null from ensureBackendCreated() if enough callers call ensureBackendCreated() at the same time, or am I missing something? > > > > > > After this change, we'll only return null here if we time out 3 times. As > > > explained in the changelog entry below, we only increment the counter upon > > > IPC timeout (or any other kind of IPC communication failure). > > > > > > So if we receive, say, 10 > > > `RemoteRenderingBackendProxy::DidCreateImageBufferBackend` responses where > > > the 10th response confirms our RemoteImageBufferProxy, we'll spin in the > > > while loop a total of 10 times and then return successfully. However, if the > > > GPU process, say, hits an infinite loop, we'll subsequently loop 3 times > > > here and then give up and return null. > > > > I'm having trouble following the logic in the code, but I think I get it. If > > RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns > > true, which happens when a sync message is received (and not a timeout) we > > just loop. > > Ah, yes — this was indeed the key bit. > > > > > I think the real issue I am having is that the function > > RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() returns a > > bool and gives no indication what that bool means (thought this seems to > > extend down in Connection::waitForAndDispatchImmediately as well). Ideally > > we would only return bools from functions that were clearly predicates. Can > > we change RemoteRenderingBackendProxy::waitForDidCreateImageBufferBackend() > > to return an enum to make it make it clear what it is saying. Otherwise, > > this code is just mysterious. > > Yep, that sounds good! Will change this to return something along the lines > of: > > enum class DidReceiveBackendCreationMessage : bool { > No, > Yes > }; I think it would be even better if the reason could be in there. Perhaps something like: enum class DidReceiveBackendCreationResult : bool { Success, TimeoutOrIPCFailure }; I am not super happy with "Success", since it might be success for a different backend, though I am not sure which word would indicate the truth succinctly. (Sorry for not being more specific before). 1714372 8 416135 wenson_hsieh 2020-12-13 20:57:26 -0800 Created attachment 416135 Patch 1714469 9 416135 wenson_hsieh 2020-12-14 09:55:07 -0800 Comment on attachment 416135 Patch Thanks for the review! 1714472 10 ews-feeder 2020-12-14 10:03:30 -0800 Committed r270775: <https://trac.webkit.org/changeset/270775> All reviewed patches have been landed. Closing bug and clearing flags on attachment 416135. 1714473 11 webkit-bug-importer 2020-12-14 10:04:19 -0800 <rdar://problem/72302200> 416124 2020-12-13 12:09:00 -0800 2020-12-13 18:40:55 -0800 Patch bug-219838-20201213120900.patch text/plain 3470 wenson_hsieh U3VidmVyc2lvbiBSZXZpc2lvbjogMjcwNzM5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDFhM2ZmOGM2ZTJjYjFmMzk3 NjNlYWU5NjBlN2UxZmZjYjBiMTRlNDYuLmExNTA3NjYzYWFjMjRhYmM0ZTQwYmEzOTczM2VmOWJh NjZmMjc1MzcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMzMgQEAKKzIwMjAtMTItMTMgIFdlbnNvbiBI c2llaCAgPHdlbnNvbl9oc2llaEBhcHBsZS5jb20+CisKKyAgICAgICAgV2ViIHByb2Nlc3MgY3Jh c2hlcyBkdXJpbmcgTW90aW9uTWFyayBJbWFnZXMgd2hlbiBHUFUgUHJvY2VzcyBmb3IgRE9NIGlz IGVuYWJsZWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIxOTgzOAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IEl0J3MgcG9zc2libGUgdG8gcmV0dXJuIHByZW1hdHVyZWx5IHdpdGggYSBudWxsIGJhY2tlbmQg d2hlbiB3YWl0aW5nIGZvciBpbWFnZSBidWZmZXIgYmFja2VuZCBjcmVhdGlvbiB1bmRlcgorICAg ICAgICBgUmVtb3RlSW1hZ2VCdWZmZXJQcm94eTo6ZW5zdXJlQmFja2VuZENyZWF0ZWQoKWAuIENv bnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8gKHdoZXJlIFdFQiBhbmQgR1BVIGRlbm90ZQor ICAgICAgICBldmVudHMgdGhhdCBvY2N1ciBpbiB0aGUgd2ViIGFuZCBHUFUgcHJvY2Vzc2VzLCBy ZXNwZWN0aXZlbHkpOgorCisgICAgICAgIDEuIChXRUIpIFJlbW90ZUltYWdlQnVmZmVyUHJveHkg QSBpcyBjcmVhdGVkIGluIHRoZSB3ZWIgcHJvY2Vzcy4KKyAgICAgICAgMi4gKEdQVSkgUmVtb3Rl SW1hZ2VCdWZmZXIgQSBpcyBjcmVhdGVkIGluIHRoZSBHUFUgcHJvY2VzcywgYWxvbmcgd2l0aCBh biBpbWFnZSBidWZmZXIgYmFja2VuZCBmb3IgQS4KKyAgICAgICAgMy4gKFdFQikgUmVtb3RlSW1h Z2VCdWZmZXJQcm94eSBCIGlzIGNyZWF0ZWQgaW4gdGhlIHdlYiBwcm9jZXNzLgorICAgICAgICA0 LiAoR1BVKSBSZW1vdGVJbWFnZUJ1ZmZlciBCIGlzIGNyZWF0ZWQgaW4gdGhlIEdQVSBwcm9jZXNz LCBhbG9uZyB3aXRoIGFuIGltYWdlIGJ1ZmZlciBiYWNrZW5kIGZvciBCLgorICAgICAgICA1LiAo V0VCKSBTb21ldGhpbmcgY2FsbHMgYFJlbW90ZUltYWdlQnVmZmVyUHJveHk6OmVuc3VyZUJhY2tl bmRDcmVhdGVkKClgIG9uIEIuCisgICAgICAgIDYuIChXRUIpIFdlIHJlY2VpdmUgdGhlIGBSZW1v dGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OkRpZENyZWF0ZUltYWdlQnVmZmVyQmFja2VuZGAgbWVz c2FnZSBmb3IgQS4KKworICAgICAgICBCIHN1YnNlcXVlbnRseSBmaW5pc2hlcyB3YWl0aW5nIGZv ciBiYWNrZW5kIGNyZWF0aW9uIGJlY2F1c2UgaXQgaW5jb3JyZWN0bHkgYmVsaWV2ZXMgdGhhdCBp dHMgYmFja2VuZCBoYXMgYmVlbgorICAgICAgICBpbml0aWFsaXplZCwgYW5kIHdlIGVuZCB1cCBj cmFzaGluZyBkb3duc3RyZWFtIGluIGBSZW1vdGVMYXllckJhY2tpbmdTdG9yZTo6ZW5jb2RlKClg IGJlY2F1c2UKKyAgICAgICAgYGVuc3VyZUJhY2tlbmRDcmVhdGVkKClgIGZvciBCIHJldHVybmVk IG51bGwuCisKKyAgICAgICAgVG8gZml4IHRoaXMsIHdlIGFkb3B0IGEgc2ltaWxhciBzdHJhdGVn eSB0byB3aGF0IHdlIHVzZSBpbiBgd2FpdEZvckRpZEZsdXNoV2l0aFRpbWVvdXQoKWAsIGFuZCBy ZXBlYXRlZGx5IGNhbGwKKyAgICAgICAgYHdhaXRGb3JEaWRDcmVhdGVJbWFnZUJ1ZmZlckJhY2tl bmQoKWAgdW50aWwgdGhlIGJhY2tlbmQgaGFzIGJlZW4gY3JlYXRlZCAoYWxsb3dpbmcgZm9yIGFu IGFyYml0cmFyeSBudW1iZXIgb2YKKyAgICAgICAgSVBDIHRpbWVvdXRzIG9yIGZhaWx1cmVzKS4g U2luY2UgdGhpcyBjb3VudGVyIGlzIG9ubHkgaW5jcmVtZW50ZWQgdXBvbiB0aW1lb3V0IChvciBh bnkgb3RoZXIga2luZCBvZiBJUEMKKyAgICAgICAgY29tbXVuaWNhdGlvbiBmYWlsdXJlKSwgd2Un bGwgc2ltcGx5IHJlY2VpdmUgYFJlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eTo6RGlkQ3JlYXRl SW1hZ2VCdWZmZXJCYWNrZW5kYCBtZXNzYWdlcworICAgICAgICB1bnRpbCB3ZSBjb25maXJtIChp biB0aGUgd2ViIHByb2Nlc3MpIHRoZSBjdXJyZW50IGltYWdlIGJ1ZmZlcidzIGJhY2tlbmQgaGFz IGJlZW4gaW5pdGlhbGl6ZWQuCisKKyAgICAgICAgKiBXZWJQcm9jZXNzL0dQVS9ncmFwaGljcy9S ZW1vdGVJbWFnZUJ1ZmZlclByb3h5Lmg6CisKIDIwMjAtMTItMTIgIFdlbnNvbiBIc2llaCAgPHdl bnNvbl9oc2llaEBhcHBsZS5jb20+CiAKICAgICAgICAgVW5yZXZpZXdlZCwgcmV2ZXJ0aW5nIHIy NzA2NzQuCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L1dlYlByb2Nlc3MvR1BVL2dyYXBoaWNz L1JlbW90ZUltYWdlQnVmZmVyUHJveHkuaCBiL1NvdXJjZS9XZWJLaXQvV2ViUHJvY2Vzcy9HUFUv Z3JhcGhpY3MvUmVtb3RlSW1hZ2VCdWZmZXJQcm94eS5oCmluZGV4IGVhY2EwMjViMzNiZTk2YTUy NWY4MzU2NzgxY2VkY2E2YjljMjM4MzQuLjkxYjQ2NTE4MjA2Njk3ZGY2MzdkMTQ1NTA4NTdlYjNm NzdhNmZjMDcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvV2ViUHJvY2Vzcy9HUFUvZ3JhcGhp Y3MvUmVtb3RlSW1hZ2VCdWZmZXJQcm94eS5oCisrKyBiL1NvdXJjZS9XZWJLaXQvV2ViUHJvY2Vz cy9HUFUvZ3JhcGhpY3MvUmVtb3RlSW1hZ2VCdWZmZXJQcm94eS5oCkBAIC0xMjksOCArMTI5LDE1 IEBAIHByb3RlY3RlZDoKIAogICAgIFdlYkNvcmU6OkltYWdlQnVmZmVyQmFja2VuZCogZW5zdXJl QmFja2VuZENyZWF0ZWQoKSBjb25zdCBvdmVycmlkZQogICAgIHsKLSAgICAgICAgaWYgKCFtX2Jh Y2tlbmQgJiYgbV9yZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHkpCi0gICAgICAgICAgICBtX3Jl bW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eS0+d2FpdEZvckRpZENyZWF0ZUltYWdlQnVmZmVyQmFj a2VuZCgpOworICAgICAgICBpZiAoIW1fcmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5KQorICAg ICAgICAgICAgcmV0dXJuIG1fYmFja2VuZC5nZXQoKTsKKworICAgICAgICBzdGF0aWMgY29uc3Rl eHByIHVuc2lnbmVkIG1heGltdW1OdW1iZXJPZlRpbWVvdXRzID0gMzsKKyAgICAgICAgdW5zaWdu ZWQgbnVtYmVyT2ZUaW1lb3V0cyA9IDA7CisgICAgICAgIHdoaWxlICghbV9iYWNrZW5kICYmIG51 bWJlck9mVGltZW91dHMgPCBtYXhpbXVtTnVtYmVyT2ZUaW1lb3V0cykgeworICAgICAgICAgICAg aWYgKCFtX3JlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eS0+d2FpdEZvckRpZENyZWF0ZUltYWdl QnVmZmVyQmFja2VuZCgpKQorICAgICAgICAgICAgICAgICsrbnVtYmVyT2ZUaW1lb3V0czsKKyAg ICAgICAgfQogICAgICAgICByZXR1cm4gbV9iYWNrZW5kLmdldCgpOwogICAgIH0KIAo= 416135 2020-12-13 20:57:26 -0800 2020-12-14 10:03:31 -0800 Patch bug-219838-20201213205725.patch text/plain 6358 wenson_hsieh U3VidmVyc2lvbiBSZXZpc2lvbjogMjcwNzUwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDFhMGRiNjJlMDlhZGVhNzJk OGNjOTIwOWM5NDk2MzU5NTI0NGI2YTQuLmY1YTNmNDg2MDNlZThjZGFhMzM4ODVmZjU4MTZhODkx ZTM0YTJmNmEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsNDAgQEAKKzIwMjAtMTItMTMgIFdlbnNvbiBI c2llaCAgPHdlbnNvbl9oc2llaEBhcHBsZS5jb20+CisKKyAgICAgICAgV2ViIHByb2Nlc3MgY3Jh c2hlcyBkdXJpbmcgTW90aW9uTWFyayBJbWFnZXMgd2hlbiBHUFUgUHJvY2VzcyBmb3IgRE9NIGlz IGVuYWJsZWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIxOTgzOAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IEl0J3MgcG9zc2libGUgdG8gcmV0dXJuIHByZW1hdHVyZWx5IHdpdGggYSBudWxsIGJhY2tlbmQg d2hlbiB3YWl0aW5nIGZvciBpbWFnZSBidWZmZXIgYmFja2VuZCBjcmVhdGlvbiB1bmRlcgorICAg ICAgICBgUmVtb3RlSW1hZ2VCdWZmZXJQcm94eTo6ZW5zdXJlQmFja2VuZENyZWF0ZWQoKWAuIENv bnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8gKHdoZXJlIFdFQiBhbmQgR1BVIGRlbm90ZQor ICAgICAgICBldmVudHMgdGhhdCBvY2N1ciBpbiB0aGUgd2ViIGFuZCBHUFUgcHJvY2Vzc2VzLCBy ZXNwZWN0aXZlbHkpOgorCisgICAgICAgIDEuIChXRUIpIFJlbW90ZUltYWdlQnVmZmVyUHJveHkg QSBpcyBjcmVhdGVkIGluIHRoZSB3ZWIgcHJvY2Vzcy4KKyAgICAgICAgMi4gKEdQVSkgUmVtb3Rl SW1hZ2VCdWZmZXIgQSBpcyBjcmVhdGVkIGluIHRoZSBHUFUgcHJvY2VzcywgYWxvbmcgd2l0aCBh biBpbWFnZSBidWZmZXIgYmFja2VuZCBmb3IgQS4KKyAgICAgICAgMy4gKFdFQikgUmVtb3RlSW1h Z2VCdWZmZXJQcm94eSBCIGlzIGNyZWF0ZWQgaW4gdGhlIHdlYiBwcm9jZXNzLgorICAgICAgICA0 LiAoR1BVKSBSZW1vdGVJbWFnZUJ1ZmZlciBCIGlzIGNyZWF0ZWQgaW4gdGhlIEdQVSBwcm9jZXNz LCBhbG9uZyB3aXRoIGFuIGltYWdlIGJ1ZmZlciBiYWNrZW5kIGZvciBCLgorICAgICAgICA1LiAo V0VCKSBTb21ldGhpbmcgY2FsbHMgYFJlbW90ZUltYWdlQnVmZmVyUHJveHk6OmVuc3VyZUJhY2tl bmRDcmVhdGVkKClgIG9uIEIuCisgICAgICAgIDYuIChXRUIpIFdlIHJlY2VpdmUgdGhlIGBSZW1v dGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OkRpZENyZWF0ZUltYWdlQnVmZmVyQmFja2VuZGAgbWVz c2FnZSBmb3IgQS4KKworICAgICAgICBCIHN1YnNlcXVlbnRseSBmaW5pc2hlcyB3YWl0aW5nIGZv ciBiYWNrZW5kIGNyZWF0aW9uIGJlY2F1c2UgaXQgaW5jb3JyZWN0bHkgYmVsaWV2ZXMgdGhhdCBp dHMgYmFja2VuZCBoYXMgYmVlbgorICAgICAgICBpbml0aWFsaXplZCwgYW5kIHdlIGVuZCB1cCBj cmFzaGluZyBkb3duc3RyZWFtIGluIGBSZW1vdGVMYXllckJhY2tpbmdTdG9yZTo6ZW5jb2RlKClg IGJlY2F1c2UKKyAgICAgICAgYGVuc3VyZUJhY2tlbmRDcmVhdGVkKClgIGZvciBCIHJldHVybmVk IG51bGwuCisKKyAgICAgICAgVG8gZml4IHRoaXMsIHdlIGFkb3B0IGEgc2ltaWxhciBzdHJhdGVn eSB0byB3aGF0IHdlIHVzZSBpbiBgd2FpdEZvckRpZEZsdXNoV2l0aFRpbWVvdXQoKWAsIGFuZCBy ZXBlYXRlZGx5IGNhbGwKKyAgICAgICAgYHdhaXRGb3JEaWRDcmVhdGVJbWFnZUJ1ZmZlckJhY2tl bmQoKWAgdW50aWwgdGhlIGJhY2tlbmQgaGFzIGJlZW4gY3JlYXRlZCAoYWxsb3dpbmcgZm9yIGFu IGFyYml0cmFyeSBudW1iZXIgb2YKKyAgICAgICAgSVBDIHRpbWVvdXRzIG9yIGZhaWx1cmVzKS4g U2luY2UgdGhpcyBjb3VudGVyIGlzIG9ubHkgaW5jcmVtZW50ZWQgdXBvbiB0aW1lb3V0IChvciBh bnkgb3RoZXIga2luZCBvZiBJUEMKKyAgICAgICAgY29tbXVuaWNhdGlvbiBmYWlsdXJlKSwgd2Un bGwgc2ltcGx5IHJlY2VpdmUgYFJlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eTo6RGlkQ3JlYXRl SW1hZ2VCdWZmZXJCYWNrZW5kYCBtZXNzYWdlcworICAgICAgICB1bnRpbCB3ZSBjb25maXJtIChp biB0aGUgd2ViIHByb2Nlc3MpIHRoYXQgdGhlIGN1cnJlbnQgaW1hZ2UgYnVmZmVyJ3MgYmFja2Vu ZCBoYXMgYmVlbiBpbml0aWFsaXplZC4KKworICAgICAgICAqIFdlYlByb2Nlc3MvR1BVL2dyYXBo aWNzL1JlbW90ZUltYWdlQnVmZmVyUHJveHkuaDoKKyAgICAgICAgKiBXZWJQcm9jZXNzL0dQVS9n cmFwaGljcy9SZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHkuY3BwOgorICAgICAgICAoV2ViS2l0 OjpSZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OndhaXRGb3JEaWRDcmVhdGVJbWFnZUJ1ZmZl ckJhY2tlbmQpOgorCisgICAgICAgIERyaXZlLWJ5IGZpeDogY2xhcmlmeSB0aGlzIGNvZGUgYnkg cmV0dXJuaW5nIGFuIGVudW0gdG8gaW5kaWNhdGUgd2hldGhlciBvciBub3Qgd2Ugc3VjY2Vzc2Z1 bGx5IHJlY2VpdmVkIGEKKyAgICAgICAgYmFja2VuZCBjcmVhdGlvbiBJUEMgcmVzcG9uc2UgZnJv bSB0aGUgR1BVIHByb2Nlc3MsIGluc3RlYWQgb2YganVzdCByZXR1cm5pbmcgYSBib29sLgorCisg ICAgICAgICogV2ViUHJvY2Vzcy9HUFUvZ3JhcGhpY3MvUmVtb3RlUmVuZGVyaW5nQmFja2VuZFBy b3h5Lmg6CisKIDIwMjAtMTItMTIgIEppZXdlbiBUYW4gIDxqaWV3ZW5fdGFuQGFwcGxlLmNvbT4K IAogICAgICAgICBbV2ViQXV0aG5dW2lPU10gVHVybiBvbiBtb2Rlcm4gV2ViQXV0aG4gZm9yIGRl ZmF1bHQgYnJvd3NlcnMKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvV2ViUHJvY2Vzcy9HUFUv Z3JhcGhpY3MvUmVtb3RlSW1hZ2VCdWZmZXJQcm94eS5oIGIvU291cmNlL1dlYktpdC9XZWJQcm9j ZXNzL0dQVS9ncmFwaGljcy9SZW1vdGVJbWFnZUJ1ZmZlclByb3h5LmgKaW5kZXggZWFjYTAyNWIz M2JlOTZhNTI1ZjgzNTY3ODFjZWRjYTZiOWMyMzgzNC4uNWVmZjA2ZDRkZjM4ZGI1NTc1ZDg4OTY5 OTE5ZWYxY2U4YzQwODU4YiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9XZWJQcm9jZXNzL0dQ VS9ncmFwaGljcy9SZW1vdGVJbWFnZUJ1ZmZlclByb3h5LmgKKysrIGIvU291cmNlL1dlYktpdC9X ZWJQcm9jZXNzL0dQVS9ncmFwaGljcy9SZW1vdGVJbWFnZUJ1ZmZlclByb3h5LmgKQEAgLTEyOSw4 ICsxMjksMTUgQEAgcHJvdGVjdGVkOgogCiAgICAgV2ViQ29yZTo6SW1hZ2VCdWZmZXJCYWNrZW5k KiBlbnN1cmVCYWNrZW5kQ3JlYXRlZCgpIGNvbnN0IG92ZXJyaWRlCiAgICAgewotICAgICAgICBp ZiAoIW1fYmFja2VuZCAmJiBtX3JlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eSkKLSAgICAgICAg ICAgIG1fcmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5LT53YWl0Rm9yRGlkQ3JlYXRlSW1hZ2VC dWZmZXJCYWNrZW5kKCk7CisgICAgICAgIGlmICghbV9yZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJv eHkpCisgICAgICAgICAgICByZXR1cm4gbV9iYWNrZW5kLmdldCgpOworCisgICAgICAgIHN0YXRp YyBjb25zdGV4cHIgdW5zaWduZWQgbWF4aW11bVRpbWVvdXRPckZhaWx1cmVDb3VudCA9IDM7Cisg ICAgICAgIHVuc2lnbmVkIG51bWJlck9mVGltZW91dHNPckZhaWx1cmVzID0gMDsKKyAgICAgICAg d2hpbGUgKCFtX2JhY2tlbmQgJiYgbnVtYmVyT2ZUaW1lb3V0c09yRmFpbHVyZXMgPCBtYXhpbXVt VGltZW91dE9yRmFpbHVyZUNvdW50KSB7CisgICAgICAgICAgICBpZiAobV9yZW1vdGVSZW5kZXJp bmdCYWNrZW5kUHJveHktPndhaXRGb3JEaWRDcmVhdGVJbWFnZUJ1ZmZlckJhY2tlbmQoKSA9PSBS ZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OkRpZFJlY2VpdmVCYWNrZW5kQ3JlYXRpb25SZXN1 bHQ6OlRpbWVvdXRPcklQQ0ZhaWx1cmUpCisgICAgICAgICAgICAgICAgKytudW1iZXJPZlRpbWVv dXRzT3JGYWlsdXJlczsKKyAgICAgICAgfQogICAgICAgICByZXR1cm4gbV9iYWNrZW5kLmdldCgp OwogICAgIH0KIApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9XZWJQcm9jZXNzL0dQVS9ncmFw aGljcy9SZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHkuY3BwIGIvU291cmNlL1dlYktpdC9XZWJQ cm9jZXNzL0dQVS9ncmFwaGljcy9SZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHkuY3BwCmluZGV4 IDRmMDliNzdjNTAyNjY4ZTFiOTU5YzE4NzY2NGI0NTQxOTIxNTBlYzUuLjE3ZTg2ZjUzY2ZhODQ2 YzNiNmY0Y2NlN2VjMjIwZGE0MzRlZjg0ZmUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvV2Vi UHJvY2Vzcy9HUFUvZ3JhcGhpY3MvUmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5LmNwcAorKysg Yi9Tb3VyY2UvV2ViS2l0L1dlYlByb2Nlc3MvR1BVL2dyYXBoaWNzL1JlbW90ZVJlbmRlcmluZ0Jh Y2tlbmRQcm94eS5jcHAKQEAgLTEwNSwxMCArMTA1LDEyIEBAIHVpbnQ2NF90IFJlbW90ZVJlbmRl cmluZ0JhY2tlbmRQcm94eTo6bWVzc2FnZVNlbmRlckRlc3RpbmF0aW9uSUQoKSBjb25zdAogICAg IHJldHVybiBtX3JlbmRlcmluZ0JhY2tlbmRJZGVudGlmaWVyLnRvVUludDY0KCk7CiB9CiAKLWJv b2wgUmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5Ojp3YWl0Rm9yRGlkQ3JlYXRlSW1hZ2VCdWZm ZXJCYWNrZW5kKCkKK1JlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eTo6RGlkUmVjZWl2ZUJhY2tl bmRDcmVhdGlvblJlc3VsdCBSZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OndhaXRGb3JEaWRD cmVhdGVJbWFnZUJ1ZmZlckJhY2tlbmQoKQogewogICAgIFJlZjxJUEM6OkNvbm5lY3Rpb24+IGNv bm5lY3Rpb24gPSBXZWJQcm9jZXNzOjpzaW5nbGV0b24oKS5lbnN1cmVHUFVQcm9jZXNzQ29ubmVj dGlvbigpLmNvbm5lY3Rpb24oKTsKLSAgICByZXR1cm4gY29ubmVjdGlvbi0+d2FpdEZvckFuZERp c3BhdGNoSW1tZWRpYXRlbHk8TWVzc2FnZXM6OlJlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eTo6 RGlkQ3JlYXRlSW1hZ2VCdWZmZXJCYWNrZW5kPihtX3JlbmRlcmluZ0JhY2tlbmRJZGVudGlmaWVy LCAxX3MsIElQQzo6V2FpdEZvck9wdGlvbjo6SW50ZXJydXB0V2FpdGluZ0lmU3luY01lc3NhZ2VB cnJpdmVzKTsKKyAgICBpZiAoIWNvbm5lY3Rpb24tPndhaXRGb3JBbmREaXNwYXRjaEltbWVkaWF0 ZWx5PE1lc3NhZ2VzOjpSZW1vdGVSZW5kZXJpbmdCYWNrZW5kUHJveHk6OkRpZENyZWF0ZUltYWdl QnVmZmVyQmFja2VuZD4obV9yZW5kZXJpbmdCYWNrZW5kSWRlbnRpZmllciwgMV9zLCBJUEM6Oldh aXRGb3JPcHRpb246OkludGVycnVwdFdhaXRpbmdJZlN5bmNNZXNzYWdlQXJyaXZlcykpCisgICAg ICAgIHJldHVybiBEaWRSZWNlaXZlQmFja2VuZENyZWF0aW9uUmVzdWx0OjpUaW1lb3V0T3JJUENG YWlsdXJlOworICAgIHJldHVybiBEaWRSZWNlaXZlQmFja2VuZENyZWF0aW9uUmVzdWx0OjpSZWNl aXZlZEFueVJlc3BvbnNlOwogfQogCiBib29sIFJlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eTo6 d2FpdEZvckRpZEZsdXNoKCkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvV2ViUHJvY2Vzcy9H UFUvZ3JhcGhpY3MvUmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5LmggYi9Tb3VyY2UvV2ViS2l0 L1dlYlByb2Nlc3MvR1BVL2dyYXBoaWNzL1JlbW90ZVJlbmRlcmluZ0JhY2tlbmRQcm94eS5oCmlu ZGV4IGQzZTQ3NDlmNWNhZTQ5ZmY1ODg2OWVhM2NiYTQ5OTFmMWY3YTMzNWYuLjkyZDRlNjg5ODQ5 ZGFkYWI5MDc4M2M3ZjNlNjdiMzM2NGYyNjA0NzYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQv V2ViUHJvY2Vzcy9HUFUvZ3JhcGhpY3MvUmVtb3RlUmVuZGVyaW5nQmFja2VuZFByb3h5LmgKKysr IGIvU291cmNlL1dlYktpdC9XZWJQcm9jZXNzL0dQVS9ncmFwaGljcy9SZW1vdGVSZW5kZXJpbmdC YWNrZW5kUHJveHkuaApAQCAtODcsNyArODcsMTEgQEAgcHVibGljOgogICAgIHZvaWQgZGVsZXRl QWxsRm9udHMoKTsKICAgICB2b2lkIHJlbGVhc2VSZW1vdGVSZXNvdXJjZShXZWJDb3JlOjpSZW5k ZXJpbmdSZXNvdXJjZUlkZW50aWZpZXIpOwogCi0gICAgYm9vbCB3YWl0Rm9yRGlkQ3JlYXRlSW1h Z2VCdWZmZXJCYWNrZW5kKCk7CisgICAgZW51bSBjbGFzcyBEaWRSZWNlaXZlQmFja2VuZENyZWF0 aW9uUmVzdWx0IDogYm9vbCB7CisgICAgICAgIFJlY2VpdmVkQW55UmVzcG9uc2UsCisgICAgICAg IFRpbWVvdXRPcklQQ0ZhaWx1cmUKKyAgICB9OworICAgIERpZFJlY2VpdmVCYWNrZW5kQ3JlYXRp b25SZXN1bHQgd2FpdEZvckRpZENyZWF0ZUltYWdlQnVmZmVyQmFja2VuZCgpOwogICAgIGJvb2wg d2FpdEZvckRpZEZsdXNoKCk7CiAKIHByaXZhdGU6Cg==