215239 2020-08-06 14:13:52 -0700 Always suspend IDB work when network process is prepared to suspend 2021-07-02 08:51:19 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=227552 InRadar P2 Normal --- 197050 1 sihui_liu sihui_liu achristensen beidson cdumez ggaren webkit-bug-importer oldest_to_newest 1678396 0 sihui_liu 2020-08-06 14:13:52 -0700 ... 1678398 1 sihui_liu 2020-08-06 14:14:28 -0700 <rdar://problem/65690450> 1678415 2 406119 sihui_liu 2020-08-06 14:30:18 -0700 Created attachment 406119 Patch 1678697 3 406119 ggaren 2020-08-07 12:56:14 -0700 Comment on attachment 406119 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406119&action=review r=me It's a little unfortunate that all transactions started before suspension will be aborted, in contrast to transactions started after suspension, which will just be paused and delayed. Is there a way to delay in progress transactions instead of aborting them? I guess not, since an in progress transaction holds a database file lock? Would it be crazy to abort a transaction without signaling an error and then put it back in the queue to try again when we resume? > Source/WebKit/ChangeLog:9 > + We do not suspend IDB work in network process when there is ongoing transaction because network process is network process => the network process ongoing transaction => an ongoing transaction network process => the network process > Source/WebKit/ChangeLog:10 > + going to ask UI process to hold process assertion for it. However, it is possible that the request from network UI process => the UI process process assertion => a process assertion network => the network > Source/WebKit/ChangeLog:11 > + process does not reach UI process before UI process thinks think it is Okay to put network process to suspend. UI process => the UI process UI process => the UI process thinks think -> thinks Okay => okay put network process to suspend => suspend the network process I believe it's runningboard, and not the UI process, that ultimately suspends the network process. So, I think this comment should talk about runningboard. Or maybe you could talk about the UI process dropping its foreground assertion on the network process? Is that what ultimately triggers runningboard to suspend the network process? > Source/WebKit/ChangeLog:12 > + In this case, IDB in network process can continue its transaction, holding file locks, and network process will network process => the network process network process => the network process > Source/WebKit/ChangeLog:13 > + be killed when it becomes suspened. Network process crash can cause worse result than aborting ongoing Network process crash => A network process crash worse result => a worse result > Source/WebKit/ChangeLog:15 > + let's just suspend IDB work when network process receives prepareToSuspend. network process => the network process 1678698 4 ggaren 2020-08-07 12:57:04 -0700 A related reason why aborting does not feel great: It will trigger more code to run when we are supposed to be suspending, since it will fire an event in the WebContent process. 1679065 5 sihui_liu 2020-08-10 09:16:10 -0700 (In reply to Geoffrey Garen from comment #3) > Comment on attachment 406119 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=406119&action=review > > r=me > > It's a little unfortunate that all transactions started before suspension > will be aborted, in contrast to transactions started after suspension, which > will just be paused and delayed. Is there a way to delay in progress > transactions instead of aborting them? I guess not, since an in progress > transaction holds a database file lock? Would it be crazy to abort a > transaction without signaling an error and then put it back in the queue to > try again when we resume? > It can be complicated. We would need to record the requests/operations of started transactions, together with their result, so we can replay them after process is resumed. But what if result of the second execution is different from the first execution; e.g. we may fire success event on some request(operation), event handler is called and a new request is created in the event handler. > > Source/WebKit/ChangeLog:9 > > + We do not suspend IDB work in network process when there is ongoing transaction because network process is > > network process => the network process > ongoing transaction => an ongoing transaction > network process => the network process > Okay. > > Source/WebKit/ChangeLog:10 > > + going to ask UI process to hold process assertion for it. However, it is possible that the request from network > > UI process => the UI process > process assertion => a process assertion > network => the network > Okay. > > Source/WebKit/ChangeLog:11 > > + process does not reach UI process before UI process thinks think it is Okay to put network process to suspend. > > UI process => the UI process > UI process => the UI process > thinks think -> thinks > Okay => okay > put network process to suspend => suspend the network process > > I believe it's runningboard, and not the UI process, that ultimately > suspends the network process. So, I think this comment should talk about > runningboard. Or maybe you could talk about the UI process dropping its > foreground assertion on the network process? Is that what ultimately > triggers runningboard to suspend the network process? > You are right, it's RunningBoard that decides it's Okay to suspend the network process after UI process drops process assertion for network process. Will update. > > Source/WebKit/ChangeLog:12 > > + In this case, IDB in network process can continue its transaction, holding file locks, and network process will > > network process => the network process > network process => the network process > Okay. > > Source/WebKit/ChangeLog:13 > > + be killed when it becomes suspened. Network process crash can cause worse result than aborting ongoing > > Network process crash => A network process crash > worse result => a worse result > Okay. > > Source/WebKit/ChangeLog:15 > > + let's just suspend IDB work when network process receives prepareToSuspend. > > network process => the network process Okay. 1679066 6 sihui_liu 2020-08-10 09:24:59 -0700 (In reply to Geoffrey Garen from comment #4) > A related reason why aborting does not feel great: It will trigger more code > to run when we are supposed to be suspending, since it will fire an event in > the WebContent process. I agree. Another possible solution would be to ensure the network process sends request for holding background assertion before the network process replies to the prepareToSuspend message. Current patch is just less risky and more straightforward to fix the crashes. 1679067 7 406299 sihui_liu 2020-08-10 09:28:22 -0700 Created attachment 406299 Patch for landing 1679073 8 ggaren 2020-08-10 09:33:22 -0700 I tend to agree that this approach is better (more likely to avoid a crash) than relying on the network process acquiring a background assertion. 1679079 9 ews-feeder 2020-08-10 09:51:23 -0700 Committed r265433: <https://trac.webkit.org/changeset/265433> All reviewed patches have been landed. Closing bug and clearing flags on attachment 406299. 1679087 10 cdumez 2020-08-10 09:54:44 -0700 Given that we had a bug that caused the PrepareToSuspend IPC to not get sent to the network process until a few days ago, I am not sure we needed to make this change. I believe the fix to actually send the PrepareToSuspend IPC has not been submitted yet so making changes to our behavior when the PrepareToSuspend IPC gets received to probably not super helpful. 1679101 11 cdumez 2020-08-10 10:10:29 -0700 (In reply to Chris Dumez from comment #10) > Given that we had a bug that caused the PrepareToSuspend IPC to not get sent > to the network process until a few days ago, I am not sure we needed to make > this change. > > I believe the fix to actually send the PrepareToSuspend IPC has not been > submitted yet so making changes to our behavior when the PrepareToSuspend > IPC gets received to probably not super helpful. http://trac.webkit.org/r265162 fixed the bug where the PrepareToSuspend IPC not getting sent in most cases. 1679104 12 sihui_liu 2020-08-10 10:18:09 -0700 (In reply to Chris Dumez from comment #11) > (In reply to Chris Dumez from comment #10) > > Given that we had a bug that caused the PrepareToSuspend IPC to not get sent > > to the network process until a few days ago, I am not sure we needed to make > > this change. > > > > I believe the fix to actually send the PrepareToSuspend IPC has not been > > submitted yet so making changes to our behavior when the PrepareToSuspend > > IPC gets received to probably not super helpful. > > http://trac.webkit.org/r265162 fixed the bug where the PrepareToSuspend IPC > not getting sent in most cases. I tested on ToT WebKit last Friday and reproduced the crash with this log: com.apple.WebKit.Networking (WebCore): SQLiteTransaction::begin() com.apple.WebKit.Networking (WebKit): NetworkProcess::prepareToSuspend(), isSuspensionImminent: 0 com.apple.WebKit.Networking (WebKit): WebSQLiteDatabaseTracker::setIsSuspended isSuspended[1] com.apple.WebKit.Networking (WebKit): NetworkProcess::prepareToSuspend() Process is ready to suspend 406119 2020-08-06 14:30:18 -0700 2020-08-10 09:28:21 -0700 Patch bug-215239-20200806143017.patch text/plain 3946 sihui_liu U3VidmVyc2lvbiBSZXZpc2lvbjogMjY1MzI0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGM5MGUwNTFmYWE5OTU0NzVj YTU0ZjEwYzAzYTkzMTk1ZjMyZDFjZTMuLjU5ZGM1ZjA4NTk1N2MwM2RkMzQwZmU4OTEzZWRhYmQ3 NDQ2NGQwMGEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjUgQEAKKzIwMjAtMDgtMDYgIFNpaHVpIExp dSAgPHNpaHVpX2xpdUBhcHBsZS5jb20+CisKKyAgICAgICAgQWx3YXlzIHN1c3BlbmQgSURCIHdv cmsgd2hlbiBuZXR3b3JrIHByb2Nlc3MgaXMgcHJlcGFyZWQgdG8gc3VzcGVuZAorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjE1MjM5CisgICAgICAgIDxy ZGFyOi8vcHJvYmxlbS82NTY5MDQ1MD4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9P UFMhKS4KKworICAgICAgICBXZSBkbyBub3Qgc3VzcGVuZCBJREIgd29yayBpbiBuZXR3b3JrIHBy b2Nlc3Mgd2hlbiB0aGVyZSBpcyBvbmdvaW5nIHRyYW5zYWN0aW9uIGJlY2F1c2UgbmV0d29yayBw cm9jZXNzIGlzIAorICAgICAgICBnb2luZyB0byBhc2sgVUkgcHJvY2VzcyB0byBob2xkIHByb2Nl c3MgYXNzZXJ0aW9uIGZvciBpdC4gSG93ZXZlciwgaXQgaXMgcG9zc2libGUgdGhhdCB0aGUgcmVx dWVzdCBmcm9tIG5ldHdvcmsKKyAgICAgICAgcHJvY2VzcyBkb2VzIG5vdCByZWFjaCBVSSBwcm9j ZXNzIGJlZm9yZSBVSSBwcm9jZXNzIHRoaW5rcyB0aGluayBpdCBpcyBPa2F5IHRvIHB1dCBuZXR3 b3JrIHByb2Nlc3MgdG8gc3VzcGVuZC4gCisgICAgICAgIEluIHRoaXMgY2FzZSwgSURCIGluIG5l dHdvcmsgcHJvY2VzcyBjYW4gY29udGludWUgaXRzIHRyYW5zYWN0aW9uLCBob2xkaW5nIGZpbGUg bG9ja3MsIGFuZCBuZXR3b3JrIHByb2Nlc3Mgd2lsbCAKKyAgICAgICAgYmUga2lsbGVkIHdoZW4g aXQgYmVjb21lcyBzdXNwZW5lZC4gTmV0d29yayBwcm9jZXNzIGNyYXNoIGNhbiBjYXVzZSB3b3Jz ZSByZXN1bHQgdGhhbiBhYm9ydGluZyBvbmdvaW5nIAorICAgICAgICB0cmFuc2FjdGlvbnMgZnJv bSBzdXNwZW5kaW5nIElEQiB3b3JrLCBhcyBpdCB3b3VsZCBkZXN0cm95IGFsbCBkYXRhYmFzZSBj b25uZWN0aW9ucyBhbmQgdHJhbnNhY3Rpb24uIFRoZXJlZm9yZSwKKyAgICAgICAgbGV0J3MganVz dCBzdXNwZW5kIElEQiB3b3JrIHdoZW4gbmV0d29yayBwcm9jZXNzIHJlY2VpdmVzIHByZXBhcmVU b1N1c3BlbmQuCisKKyAgICAgICAgKiBOZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2Vy dmVyLmNwcDoKKyAgICAgICAgKFdlYktpdDo6V2ViSURCU2VydmVyOjpzdXNwZW5kKToKKyAgICAg ICAgKiBOZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2VydmVyLmg6CisgICAgICAgICog TmV0d29ya1Byb2Nlc3MvTmV0d29ya1Byb2Nlc3MuY3BwOgorICAgICAgICAoV2ViS2l0OjpOZXR3 b3JrUHJvY2Vzczo6cHJlcGFyZVRvU3VzcGVuZCk6CisKIDIwMjAtMDgtMDYgIEphbWVzIFNhdmFn ZSAgPGphbWVzLnNhdmFnZUBhcHBsZS5jb20+CiAKICAgICAgICAgQ291bGQgbm90IGZpbmQgbW9k dWxlICdXZWJLaXQnIGZvciB0YXJnZXQgJ2FybXY3LWFwcGxlLWlvcycKZGlmZiAtLWdpdCBhL1Nv dXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvSW5kZXhlZERCL1dlYklEQlNlcnZlci5jcHAgYi9T b3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL0luZGV4ZWREQi9XZWJJREJTZXJ2ZXIuY3BwCmlu ZGV4IDI3MGJlN2E1N2U5MzkxODEyNzY4YmY0YWU1ZjkwMTg3MTQ4NzYyMmEuLjk3MTEyNWIxY2Nm YzljODQzNTM0ZDM2MDAzMDdlYTE0MmE4ZWRhZTYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQv TmV0d29ya1Byb2Nlc3MvSW5kZXhlZERCL1dlYklEQlNlcnZlci5jcHAKKysrIGIvU291cmNlL1dl YktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2VydmVyLmNwcApAQCAtMTAyLDEz ICsxMDIsMTAgQEAgdm9pZCBXZWJJREJTZXJ2ZXI6OnJlbmFtZU9yaWdpbihjb25zdCBXZWJDb3Jl OjpTZWN1cml0eU9yaWdpbkRhdGEmIG9sZE9yaWdpbiwgY28KICAgICB9KTsKIH0KIAotdm9pZCBX ZWJJREJTZXJ2ZXI6OnN1c3BlbmQoU2hvdWxkRm9yY2VTdG9wIHNob3VsZEZvcmNlU3RvcCkKK3Zv aWQgV2ViSURCU2VydmVyOjpzdXNwZW5kKCkKIHsKICAgICBBU1NFUlQoUnVuTG9vcDo6aXNNYWlu KCkpOwogCi0gICAgaWYgKHNob3VsZEZvcmNlU3RvcCA9PSBTaG91bGRGb3JjZVN0b3A6Ok5vICYm IFdlYkNvcmU6OlNRTGl0ZURhdGFiYXNlVHJhY2tlcjo6aGFzVHJhbnNhY3Rpb25JblByb2dyZXNz KCkpCi0gICAgICAgIHJldHVybjsKLQogICAgIGlmIChtX2lzU3VzcGVuZGVkKQogICAgICAgICBy ZXR1cm47CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvSW5kZXhl ZERCL1dlYklEQlNlcnZlci5oIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVk REIvV2ViSURCU2VydmVyLmgKaW5kZXggOTY3YTk3YzJiZTcyMzhjMjA3Nzg0YTU3ZDM1MjQ2NjQ1 ZmQ5ZjZmZi4uZjc5YjNmMDhmOTBlMmM5NTZlY2RhN2I3YTMxZDE3ZTdmYTMxYzExMSAxMDA2NDQK LS0tIGEvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2VydmVy LmgKKysrIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2Vy dmVyLmgKQEAgLTUxLDggKzUxLDcgQEAgcHVibGljOgogICAgIHZvaWQgY2xvc2VBbmREZWxldGVE YXRhYmFzZXNGb3JPcmlnaW5zKGNvbnN0IFZlY3RvcjxXZWJDb3JlOjpTZWN1cml0eU9yaWdpbkRh dGE+JiwgQ29tcGxldGlvbkhhbmRsZXI8dm9pZCgpPiYmIGNhbGxiYWNrKTsKICAgICB2b2lkIHJl bmFtZU9yaWdpbihjb25zdCBXZWJDb3JlOjpTZWN1cml0eU9yaWdpbkRhdGEmLCBjb25zdCBXZWJD b3JlOjpTZWN1cml0eU9yaWdpbkRhdGEmLCBDb21wbGV0aW9uSGFuZGxlcjx2b2lkKCk+JiYpOwog Ci0gICAgZW51bSBjbGFzcyBTaG91bGRGb3JjZVN0b3AgOiBib29sIHsgTm8sIFllcyB9OwotICAg IHZvaWQgc3VzcGVuZChTaG91bGRGb3JjZVN0b3ApOworICAgIHZvaWQgc3VzcGVuZCgpOwogICAg IHZvaWQgcmVzdW1lKCk7CiAKICAgICAvLyBNZXNzYWdlIGhhbmRsZXJzLgpkaWZmIC0tZ2l0IGEv U291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9OZXR3b3JrUHJvY2Vzcy5jcHAgYi9Tb3VyY2Uv V2ViS2l0L05ldHdvcmtQcm9jZXNzL05ldHdvcmtQcm9jZXNzLmNwcAppbmRleCA3OTA4NTdkNTc2 YjE1NDRmMzJjMzAwNWM4ZTM3OWFlOTgzZDMzYmFlLi4zZjczOGFmNGQ1ZTc5ZmI3MGEwN2M5OWFj NzkwZDNkOWVkYjM2OTVkIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNz L05ldHdvcmtQcm9jZXNzLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL05l dHdvcmtQcm9jZXNzLmNwcApAQCAtMjI3MSw3ICsyMjcxLDcgQEAgdm9pZCBOZXR3b3JrUHJvY2Vz czo6cHJlcGFyZVRvU3VzcGVuZChib29sIGlzU3VzcGVuc2lvbkltbWluZW50LCBDb21wbGV0aW9u SGFuZGwKIAogI2lmIFBMQVRGT1JNKElPU19GQU1JTFkpICYmIEVOQUJMRShJTkRFWEVEX0RBVEFC QVNFKQogICAgIGZvciAoYXV0byYgc2VydmVyIDogbV93ZWJJREJTZXJ2ZXJzLnZhbHVlcygpKQot ICAgICAgICBzZXJ2ZXItPnN1c3BlbmQoaXNTdXNwZW5zaW9uSW1taW5lbnQgPyBXZWJJREJTZXJ2 ZXI6OlNob3VsZEZvcmNlU3RvcDo6WWVzIDogV2ViSURCU2VydmVyOjpTaG91bGRGb3JjZVN0b3A6 Ok5vKTsKKyAgICAgICAgc2VydmVyLT5zdXNwZW5kKCk7CiAjZW5kaWYKIAogI2lmIFBMQVRGT1JN KElPU19GQU1JTFkpCg== 406299 2020-08-10 09:28:22 -0700 2020-08-10 09:51:23 -0700 Patch for landing bug-215239-20200810092822.patch text/plain 4126 sihui_liu U3VidmVyc2lvbiBSZXZpc2lvbjogMjY1NDI5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGJjZjI3NzI1ODZmNzFjOTA5 MTg5NmM2MWQ1ZGExZTBlYTk4ZDRmNzguLjM3ZmU4MWI5Y2Q3MWY3MzA1NGVhY2FhYjI5MDNmN2Zm ZWM3NTFmYjEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjkgQEAKKzIwMjAtMDgtMTAgIFNpaHVpIExp dSAgPHNpaHVpX2xpdUBhcHBsZS5jb20+CisKKyAgICAgICAgQWx3YXlzIHN1c3BlbmQgSURCIHdv cmsgd2hlbiBuZXR3b3JrIHByb2Nlc3MgaXMgcHJlcGFyZWQgdG8gc3VzcGVuZAorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjE1MjM5CisgICAgICAgIDxy ZGFyOi8vcHJvYmxlbS82NTY5MDQ1MD4KKworICAgICAgICBSZXZpZXdlZCBieSBHZW9mZnJleSBH YXJlbi4KKworICAgICAgICBXZSBkbyBub3Qgc3VzcGVuZCBJREIgd29yayBpbiB0aGUgbmV0d29y ayBwcm9jZXNzIHdoZW4gdGhlcmUgaXMgYW4gb25nb2luZyB0cmFuc2FjdGlvbiBiZWNhdXNlIHRo ZSBuZXR3b3JrIAorICAgICAgICBwcm9jZXNzIGlzIGdvaW5nIHRvIGFzayB0aGUgVUkgcHJvY2Vz cyB0byBob2xkIGEgYmFja2dyb3VuZCBwcm9jZXNzIGFzc2VydGlvbiBmb3IgaXQuIEhvd2V2ZXIs IGl0IGlzIHBvc3NpYmxlIAorICAgICAgICB0aGF0IHRoZSByZXF1ZXN0IGZyb20gdGhlIG5ldHdv cmsgcHJvY2VzcyBkb2VzIG5vdCByZWFjaCB0aGUgVUkgcHJvY2VzcyBpbiB0aW1lOiBSdW5uaW5n Qm9hcmQgbWF5IGFscmVhZHkgZGVjaWRlCisgICAgICAgIHRvIHN1c3BlbmQgdGhlIG5ldHdvcmsg cHJvY2VzcyBhZnRlciBhcHAgaXMgYmFja2dyb3VuZGVkIGFuZCBVSSBwcm9jZXNzIGRyb3BzIHRo ZSBmb3JlZ3JvdW5kIGFzc2VydGlvbiBmb3IgdGhlIAorICAgICAgICBuZXR3b3JrIHByb2Nlc3Mu IAorCisgICAgICAgIEluIHRoaXMgY2FzZSwgSURCIGluIHRoZSBuZXR3b3JrIHByb2Nlc3Mgd291 bGQgY29udGludWUgaXRzIHRyYW5zYWN0aW9uIGFuZCB0aGUgbmV0d29yayBwcm9jZXNzIHdpbGwg YmUga2lsbGVkIAorICAgICAgICB3aGVuIGl0IGJlY29tZXMgc3VzcGVuZWQgZm9yIGhvbGRpbmcg ZGF0YWJhc2UgZmlsZSBsb2Nrcy4gQSBuZXR3b3JrIHByb2Nlc3MgY3Jhc2ggY2FuIGxlYWQgdG8g YSB3b3JzZSByZXN1bHQgCisgICAgICAgIHRoYW4gc3VzcGVuZGluZyBJREIgd29yaywgd2hpY2gg YWJvcnRzIG9uZ29pbmcgdHJhbnNhY3Rpb25zLCBiZWNhdXNlIGl0IHdpbGwgZGVzdHJveSBhbGwg ZGF0YWJhc2UgY29ubmVjdGlvbnMgCisgICAgICAgIGFuZCB0cmFuc2FjdGlvbi4gVGhlcmVmb3Jl LCBsZXQncyBqdXN0IHN1c3BlbmQgSURCIHdvcmsgd2hlbiB0aGUgbmV0d29yayBwcm9jZXNzIHJl Y2VpdmVzIHByZXBhcmVUb1N1c3BlbmQgCisgICAgICAgIG1lc3NhZ2UuCisKKyAgICAgICAgKiBO ZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2VydmVyLmNwcDoKKyAgICAgICAgKFdlYktp dDo6V2ViSURCU2VydmVyOjpzdXNwZW5kKToKKyAgICAgICAgKiBOZXR3b3JrUHJvY2Vzcy9JbmRl eGVkREIvV2ViSURCU2VydmVyLmg6CisgICAgICAgICogTmV0d29ya1Byb2Nlc3MvTmV0d29ya1By b2Nlc3MuY3BwOgorICAgICAgICAoV2ViS2l0OjpOZXR3b3JrUHJvY2Vzczo6cHJlcGFyZVRvU3Vz cGVuZCk6CisKIDIwMjAtMDgtMTAgIFBlciBBcm5lIFZvbGxhbiAgPHB2b2xsYW5AYXBwbGUuY29t PgogCiAgICAgICAgIEFkZCByZXF1aXJlZCBlbnRpdGxlbWVudCBmb3IgQ2F0YWx5c3QKZGlmZiAt LWdpdCBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvSW5kZXhlZERCL1dlYklEQlNlcnZl ci5jcHAgYi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL0luZGV4ZWREQi9XZWJJREJTZXJ2 ZXIuY3BwCmluZGV4IDI3MGJlN2E1N2U5MzkxODEyNzY4YmY0YWU1ZjkwMTg3MTQ4NzYyMmEuLjk3 MTEyNWIxY2NmYzljODQzNTM0ZDM2MDAzMDdlYTE0MmE4ZWRhZTYgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvSW5kZXhlZERCL1dlYklEQlNlcnZlci5jcHAKKysrIGIv U291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2ViSURCU2VydmVyLmNwcApA QCAtMTAyLDEzICsxMDIsMTAgQEAgdm9pZCBXZWJJREJTZXJ2ZXI6OnJlbmFtZU9yaWdpbihjb25z dCBXZWJDb3JlOjpTZWN1cml0eU9yaWdpbkRhdGEmIG9sZE9yaWdpbiwgY28KICAgICB9KTsKIH0K IAotdm9pZCBXZWJJREJTZXJ2ZXI6OnN1c3BlbmQoU2hvdWxkRm9yY2VTdG9wIHNob3VsZEZvcmNl U3RvcCkKK3ZvaWQgV2ViSURCU2VydmVyOjpzdXNwZW5kKCkKIHsKICAgICBBU1NFUlQoUnVuTG9v cDo6aXNNYWluKCkpOwogCi0gICAgaWYgKHNob3VsZEZvcmNlU3RvcCA9PSBTaG91bGRGb3JjZVN0 b3A6Ok5vICYmIFdlYkNvcmU6OlNRTGl0ZURhdGFiYXNlVHJhY2tlcjo6aGFzVHJhbnNhY3Rpb25J blByb2dyZXNzKCkpCi0gICAgICAgIHJldHVybjsKLQogICAgIGlmIChtX2lzU3VzcGVuZGVkKQog ICAgICAgICByZXR1cm47CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nl c3MvSW5kZXhlZERCL1dlYklEQlNlcnZlci5oIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vz cy9JbmRleGVkREIvV2ViSURCU2VydmVyLmgKaW5kZXggOTY3YTk3YzJiZTcyMzhjMjA3Nzg0YTU3 ZDM1MjQ2NjQ1ZmQ5ZjZmZi4uZjc5YjNmMDhmOTBlMmM5NTZlY2RhN2I3YTMxZDE3ZTdmYTMxYzEx MSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIvV2Vi SURCU2VydmVyLmgKKysrIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9JbmRleGVkREIv V2ViSURCU2VydmVyLmgKQEAgLTUxLDggKzUxLDcgQEAgcHVibGljOgogICAgIHZvaWQgY2xvc2VB bmREZWxldGVEYXRhYmFzZXNGb3JPcmlnaW5zKGNvbnN0IFZlY3RvcjxXZWJDb3JlOjpTZWN1cml0 eU9yaWdpbkRhdGE+JiwgQ29tcGxldGlvbkhhbmRsZXI8dm9pZCgpPiYmIGNhbGxiYWNrKTsKICAg ICB2b2lkIHJlbmFtZU9yaWdpbihjb25zdCBXZWJDb3JlOjpTZWN1cml0eU9yaWdpbkRhdGEmLCBj b25zdCBXZWJDb3JlOjpTZWN1cml0eU9yaWdpbkRhdGEmLCBDb21wbGV0aW9uSGFuZGxlcjx2b2lk KCk+JiYpOwogCi0gICAgZW51bSBjbGFzcyBTaG91bGRGb3JjZVN0b3AgOiBib29sIHsgTm8sIFll cyB9OwotICAgIHZvaWQgc3VzcGVuZChTaG91bGRGb3JjZVN0b3ApOworICAgIHZvaWQgc3VzcGVu ZCgpOwogICAgIHZvaWQgcmVzdW1lKCk7CiAKICAgICAvLyBNZXNzYWdlIGhhbmRsZXJzLgpkaWZm IC0tZ2l0IGEvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9OZXR3b3JrUHJvY2Vzcy5jcHAg Yi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL05ldHdvcmtQcm9jZXNzLmNwcAppbmRleCA1 MzI4MzYwZjM5MDA3NzZjYjM0MGY3YTdlMjI1NDg5ZWM0ZWJkZWExLi5mNmI4NjBlNzliM2E2Zjc1 NGFlMWFkYzQzMmUxNTRlOWRmYzhmMjIxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L05ldHdv cmtQcm9jZXNzL05ldHdvcmtQcm9jZXNzLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQ cm9jZXNzL05ldHdvcmtQcm9jZXNzLmNwcApAQCAtMjI4OCw3ICsyMjg4LDcgQEAgdm9pZCBOZXR3 b3JrUHJvY2Vzczo6cHJlcGFyZVRvU3VzcGVuZChib29sIGlzU3VzcGVuc2lvbkltbWluZW50LCBD b21wbGV0aW9uSGFuZGwKIAogI2lmIFBMQVRGT1JNKElPU19GQU1JTFkpICYmIEVOQUJMRShJTkRF WEVEX0RBVEFCQVNFKQogICAgIGZvciAoYXV0byYgc2VydmVyIDogbV93ZWJJREJTZXJ2ZXJzLnZh bHVlcygpKQotICAgICAgICBzZXJ2ZXItPnN1c3BlbmQoaXNTdXNwZW5zaW9uSW1taW5lbnQgPyBX ZWJJREJTZXJ2ZXI6OlNob3VsZEZvcmNlU3RvcDo6WWVzIDogV2ViSURCU2VydmVyOjpTaG91bGRG b3JjZVN0b3A6Ok5vKTsKKyAgICAgICAgc2VydmVyLT5zdXNwZW5kKCk7CiAjZW5kaWYKIAogI2lm IFBMQVRGT1JNKElPU19GQU1JTFkpCg==