84488 2012-04-20 13:43:03 -0700 Extra work done by PageGroupLoadDeferrer besides Page::setDefersLoading needs to be done by Page::setDefersLoading 2014-08-06 22:12:12 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All All ASSIGNED InRadar P2 Normal --- 84490 1 beidson beidson ap darin dbates jchaffraix psolanki yong.li.webkit oldest_to_newest 606860 0 beidson 2012-04-20 13:43:03 -0700 Extra work done by PageGroupLoadDeferrer besides Page::setDefersLoading needs to be done by Page::setDefersLoading At least one platform (Mac) exposes Page::setDefersLoading in their API. PageGroupLoadDeferrer does extra work that is important for deferring loading but that extra work is skipped when APIs defer loading directly. To further exacerbate this problem at least some sections of the code conflate "page->defersLoading()" with "PageGroupLoadDeferrer's extra work has been done". One example is Document::didReceiveTask. If page->defersLoading() is true, it throws the task on a pending queue. But that queue is only flushed when a PageGroupLoadDeferrer is destroyed, and not when the state of page->defersLoading() otherwise changes. This was introduced in 102278 and caused a lot of bizarre little side effects. --- One complication in this cleanup will addressing this long-time comment in PageGroupLoadDefererr: // NOTE: if PageGroupLoadDeferrer is ever used for tasks other than showing a modal window or sheet, // the constructor will need to take a ActiveDOMObject::ReasonForSuspension. The time for addressing that is overdue! In radar as <rdar://problem/10484294> 606914 1 beidson 2012-04-20 14:30:15 -0700 Fixed the comment in https://bugs.webkit.org/show_bug.cgi?id=84490 and http://trac.webkit.org/changeset/114782 Now on to the real work. 606916 2 beidson 2012-04-20 14:33:22 -0700 Another interesting thing about this work was that the extra PageGroupLoadDeferrer work didn't respect m_settings->loadDeferringEnabled() on a page-by-page basis. It should have. 606929 3 beidson 2012-04-20 14:50:27 -0700 As I started working on a patch, it became apparent that: >To further exacerbate this problem at least some sections of the code conflate "page->defersLoading()" with "PageGroupLoadDeferrer's extra work has been done". Is actually the key problem behind <rdar://problem/10484294>. While this bug is still very real and should remain open, a larger overhaul might not be necessary right now... back with more soon. 606933 4 yong.li.webkit 2012-04-20 14:52:39 -0700 Do you know why Page::setDefersLoading() is used instead of PageGroupLoadDeferrer? Everyone should use PageGroupLoadDeferrer from my point of view, because the order of destructing them is critical. Be careful with script debugger. They are doing partial defer work, too. void PageScriptDebugServer::setJavaScriptPaused(Frame* frame, bool paused) { ASSERT_ARG(frame, frame); if (!frame->script()->canExecuteScripts(NotAboutToExecuteScript)) return; frame->script()->setPaused(paused); Document* document = frame->document(); if (paused) { document->suspendScriptedAnimationControllerCallbacks(); document->suspendActiveDOMObjects(ActiveDOMObject::JavaScriptDebuggerPaused); } else { document->resumeActiveDOMObjects(); document->resumeScriptedAnimationControllerCallbacks(); } setJavaScriptPaused(frame->view(), paused); } 606941 5 beidson 2012-04-20 14:59:38 -0700 (In reply to comment #3) > As I started working on a patch, it became apparent that: > > >To further exacerbate this problem at least some sections of the code conflate "page->defersLoading()" with "PageGroupLoadDeferrer's extra work has been done". > > Is actually the key problem behind <rdar://problem/10484294>. It's the first half of the problem. The second half of the problem is that when Page::setDefersLoading(false) is called no one tells the Document to resume performing its callbacks. I think the "extra" code really does need to be moved into the active part of Page::setDefersLoading() 606944 6 beidson 2012-04-20 15:03:59 -0700 (In reply to comment #4) > Do you know why Page::setDefersLoading() is used instead of PageGroupLoadDeferrer? Everyone should use PageGroupLoadDeferrer from my point of view, because the order of destructing them is critical. Yes... because it is Mac API that has existed since the beginning of the WebKit project, and Cocoa clients use it. PageGroupLoadDeferrer was added much later as a "temporary load deferring locker" meant to have stack lifetime. But by the time it was added Cocoa clients had already established a precedent of deferring/undeferring on their own terms. The moment PageGroupLoadDeferrer did any additional work besides calling Page::setDefersLoading(), that was a bug introduced to Cocoa clients. Such are the concerns of maintaining a widely used API... > Be careful with script debugger. They are doing partial defer work, too. > > void PageScriptDebugServer::setJavaScriptPaused(Frame* frame, bool paused) > { > ASSERT_ARG(frame, frame); > > if (!frame->script()->canExecuteScripts(NotAboutToExecuteScript)) > return; > > frame->script()->setPaused(paused); > > Document* document = frame->document(); > if (paused) { > document->suspendScriptedAnimationControllerCallbacks(); > document->suspendActiveDOMObjects(ActiveDOMObject::JavaScriptDebuggerPaused); > } else { > document->resumeActiveDOMObjects(); > document->resumeScriptedAnimationControllerCallbacks(); > } > > setJavaScriptPaused(frame->view(), paused); > } This is not a concern as these are all mechanisms separate from load deferring, and are not exposed as API. The crux of the problem was introducing two different load deferring behaviors. 606955 7 beidson 2012-04-20 15:21:20 -0700 (In reply to comment #6) > (In reply to comment #4) > > Do you know why Page::setDefersLoading() is used instead of PageGroupLoadDeferrer? Everyone should use PageGroupLoadDeferrer from my point of view, because the order of destructing them is critical. > > Yes... because it is Mac API that has existed since the beginning of the WebKit project, and Cocoa clients use it. And another key reason is that they defer loads on a per-Page basis instead of a per-PageGroup basis. 606960 8 beidson 2012-04-20 15:24:19 -0700 (In reply to comment #6) > (In reply to comment #4) > > Do you know why Page::setDefersLoading() is used instead of PageGroupLoadDeferrer? Everyone should use PageGroupLoadDeferrer from my point of view, because the order of destructing them is critical. On a per-page basis, it shouldn't be difficult to preserve the order of operations that PageGroupLoadDeferrer currently enforces. But if your assertion is that it is important that all of the document scheduled task suspension must take place before all of the actual calls to setDefersLoading... I would have to ask for clarification as to why. 607022 9 beidson 2012-04-20 16:29:48 -0700 All of these different ActiveDOMObject::ReasonForSuspension cases are amusing. If you grep the project you find that precisely *ONE* ActiveDOMObject (HTMLMediaElement) behaves differently based on only *one* of the flags. In other words, WillShowDialog carries absolutely zero special significance and can be renamed to "WillDeferLoading" then used generically in all load deferring code paths. 607028 10 beidson 2012-04-20 16:31:54 -0700 Which means that much of https://bugs.webkit.org/show_bug.cgi?id=84490 and http://trac.webkit.org/changeset/114782 were unnecessary (though the Document parts still were) But as a logical step forward it was still a good exploration. 607077 11 beidson 2012-04-20 17:08:10 -0700 Renamed WillShowDialog to WillDeferLoading in http://trac.webkit.org/changeset/114802 607099 12 138207 beidson 2012-04-20 17:48:05 -0700 Created attachment 138207 Patch v1 - Fold the extra work in to the common method 607103 13 beidson 2012-04-20 17:49:07 -0700 (In reply to comment #12) > Created an attachment (id=138207) [details] > Patch v1 - Fold the extra work in to the common method Realistically I'd be surprised if this changed behavior for WebCore or any other WebKit clients that haven't exposed setDefersLoading directly. But Yong had some concerns, so here is my proposed patch for him to look at. 607698 14 yong.li.webkit 2012-04-23 08:18:30 -0700 Brady, I tried doing the similar change before. But it caused assert failures because of conflicts with other calls to page->setDefersLoading(). If the API must call setDefersLoading() by themselves, we probably should make m_defersLoading a counter. Otherwise, the following senario could happen: Executing JS ... To show a modal dialog setDefersLoading(true) (by PageGroupLoadDeferrer) ... setDefersLoading(true) (by API) ... setDefersLoading(false) (by API) ... (!!!tasks are assumed here!!!) ... Executing JS when showing modal dialog. Re-entrancy ... setDefersLoading(false) (by PageGroupLoadDeferrer) 607746 15 beidson 2012-04-23 09:20:48 -0700 (In reply to comment #14) > > If the API must call setDefersLoading() by themselves, They already do. We must continue supporting it. And there's already real world breakage with a long standing Apple internal project, and fixing that is my primary task right now. > Brady, I tried doing the similar change before. But it caused assert failures because of conflicts with other calls to page->setDefersLoading(). Can you provide a concrete example of where this happened, and what the backtraces were? > we probably should make m_defersLoading a counter. Otherwise, the following senario could happen: > > Executing JS > ... > To show a modal dialog > setDefersLoading(true) (by PageGroupLoadDeferrer) > ... > setDefersLoading(true) (by API) > ... > setDefersLoading(false) (by API) > ... > (!!!tasks are assumed here!!!) > ... > Executing JS when showing modal dialog. Re-entrancy > ... > setDefersLoading(false) (by PageGroupLoadDeferrer) I agree it should be a counter... In addition to the theoretical bug of Mac WebKit API users of setDefersLoading() interacting poorly with PageGroupLoadDeferrers, there's already an obviously real bug in WebKit/chromium in that they use a stack of PageGroupLoadDeferrers for entering/exiting modal loops. I do not think the stack behaves the way they think it behaves... 607751 16 beidson 2012-04-23 09:24:43 -0700 Just as a heads up: The current state of things is very broken and sorting it out is very high priority for us. I fully respect that you've done the most recent work in this area and hope to keep getting your feedback, but I have to be moving forward quickly on this and code changes will need to be happening very soon. 607793 17 138207 beidson 2012-04-23 10:21:54 -0700 Comment on attachment 138207 Patch v1 - Fold the extra work in to the common method Running layout tests shows inspector failures related to load deferring. Now that I have firms examples of the asserts Yong alluded too, I'll work on other approaches. 608057 18 darin 2012-04-23 15:11:45 -0700 We may need to roll out r102278 if we aren’t able to resolve this soon. 608114 19 beidson 2012-04-23 15:45:16 -0700 (In reply to comment #18) > We may need to roll out r102278 if we aren’t able to resolve this soon. I found another way to resolve the radar <rdar://problem/10484294> that makes figuring this out in WebKit less pressing. But this bug should remain open to track the work that still needs to be done for future sanities sake. 1027417 20 dbates 2014-08-06 22:12:12 -0700 (In reply to comment #0) > One example is Document::didReceiveTask. If page->defersLoading() is true, it throws the task on a pending queue. But that queue is only flushed when a PageGroupLoadDeferrer is destroyed, and not when the state of page->defersLoading() otherwise changes. This was introduced in 102278 and caused a lot of bizarre little side effects. I broke out a fix for this issue into bug #135688 from the larger refactoring effort proposed by this bug. 138207 2012-04-20 17:48:05 -0700 2012-04-23 10:21:54 -0700 Patch v1 - Fold the extra work in to the common method patch.txt text/plain 4935 beidson ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCBmYWEwY2UzLi5hZTg5OGMxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDUgKzEsMzIg QEAKIDIwMTItMDQtMjAgIEJyYWR5IEVpZHNvbiAgPGJlaWRzb25AYXBwbGUuY29tPgogCisgICAg ICAgIDxyZGFyOi8vcHJvYmxlbS8xMDQ4NDI5ND4gYW5kIGh0dHBzOi8vYnVncy53ZWJraXQub3Jn L3Nob3dfYnVnLmNnaT9pZD04NDQ4OAorICAgICAgICBFeHRyYSB3b3JrIGRvbmUgYnkgUGFnZUdy b3VwTG9hZERlZmVycmVyIG5lZWRzIHRvIGJlIGRvbmUgaW5zaWRlIFBhZ2U6OnNldERlZmVyc0xv YWRpbmcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBN YWMgV2ViS2l0IEFQSSBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byBtYW51YWxseSBkZWZlciBhbmQg cmVzdW1lIHBhZ2UgbG9hZGluZyBvbiBhIHBlci1QYWdlIGJhc2lzLgorICAgICAgICBJdCB1c2Vz IFBhZ2U6OnNldERlZmVyc0xvYWRpbmcgdG8gYWNjb21wbGlzaCB0aGlzLgorCisgICAgICAgIFBh Z2VHcm91cExvYWREZWZlcnJlciBkb2VzIGV4dHJhIHdvcmsgb3V0c2lkZSBvZiBQYWdlOjpzZXRE ZWZlcnNMb2FkaW5nIHRoYXQgc2hvdWxkIHJlYWxseSBqdXN0IGJlIGZvbGRlZAorICAgICAgICBp biB0byB0aGF0IGNvbW1vbiBtZXRob2QuCisKKyAgICAgICAgTm8gbmV3IHRlc3RzLiAgTW9zdGx5 IGEgcmVmYWN0b3IuCisgICAgICAgIFRoZSBjaGFuZ2UgaW4gYmVoYXZpb3Igc2hvdWxkIG9ubHkg YmUgb2JzZXJ2YWJsZSB0byBNYWMgV2ViS2l0MSBBUEkgY2xpZW50cyB0aGF0IGFyZSBub3QgcHJh Y3RpY2FsIHRvIHRlc3QKKyAgICAgICAgd2l0aCBjdXJyZW50IGluZnJhc3RydWN0dXJlLgorCisg ICAgICAgICogcGFnZS9QYWdlLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlBhZ2U6OnNldERlZmVy c0xvYWRpbmcpOiBTdXNwZW5kIHNjaGVkdWxlZCB0YXNrcyBvbiBhbGwgRG9jdW1lbnRzIGlmIGRl ZmVycmluZyBpcyBiZWluZyBlbmFibGVkLAorICAgICAgICAgICB0aGVuIGNoYW5nZSB0aGUgZGVm ZXJyZWQgbG9hZGluZyBmbGFnLCB0aGVuIHJlc3VtZSBzY2hlZHVsZWQgdGFza3MgaWYgZGVmZXJy aW5nIGlzIGJlaW5nIGRpc2FibGVkLgorCisgICAgICAgICogcGFnZS9QYWdlR3JvdXBMb2FkRGVm ZXJyZXIuY3BwOgorICAgICAgICAoV2ViQ29yZTo6UGFnZUdyb3VwTG9hZERlZmVycmVyOjpQYWdl R3JvdXBMb2FkRGVmZXJyZXIpOiBSZWx5IG9uIFBhZ2U6OnNldERlZmVyc0xvYWRpbmcgdG8gZG8g dGhlCisgICAgICAgICAgc2NoZWR1bGVkIHRhc2sgc3VzcGVuZGluZy4KKyAgICAgICAgKFdlYkNv cmU6OlBhZ2VHcm91cExvYWREZWZlcnJlcjo6flBhZ2VHcm91cExvYWREZWZlcnJlcik6IFJlbHkg b24gUGFnZTo6c2V0RGVmZXJzTG9hZGluZyB0byBkbyB0aGUKKyAgICAgICAgICBzY2hlZHVsZWQg dGFzayByZXN1bWluZy4KKworMjAxMi0wNC0yMCAgQnJhZHkgRWlkc29uICA8YmVpZHNvbkBhcHBs ZS5jb20+CisKICAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTg0NTEyCiAgICAgICAgIFJlcHVycG9zZSBBY3RpdmVET01PYmplY3Q6OldpbGxTaG93RGlhbG9n IHRvIFdpbGxEZWZlckxvYWRpbmcKIApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGFnZS9Q YWdlLmNwcCBiL1NvdXJjZS9XZWJDb3JlL3BhZ2UvUGFnZS5jcHAKaW5kZXggZDE1YjE2Zi4uOGMw ZmY1MCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGFnZS9QYWdlLmNwcAorKysgYi9Tb3Vy Y2UvV2ViQ29yZS9wYWdlL1BhZ2UuY3BwCkBAIC01NjksMTUgKzU2OSwyNyBAQCBjb25zdCBWaXNp YmxlU2VsZWN0aW9uJiBQYWdlOjpzZWxlY3Rpb24oKSBjb25zdAogCiB2b2lkIFBhZ2U6OnNldERl ZmVyc0xvYWRpbmcoYm9vbCBkZWZlcnMpCiB7Ci0gICAgaWYgKCFtX3NldHRpbmdzLT5sb2FkRGVm ZXJyaW5nRW5hYmxlZCgpKQotICAgICAgICByZXR1cm47Ci0KICAgICBpZiAoZGVmZXJzID09IG1f ZGVmZXJzTG9hZGluZykKICAgICAgICAgcmV0dXJuOworICAgICAgICAKKyAgICBpZiAoZGVmZXJz KSB7CisgICAgICAgIC8vIFdlIGRvIG5vdCB3YW50IGphdmFzY3JpcHQgb3Igb3RoZXIgYXlzbmNo cm9ub3VzIERPTSBldmVudHMgb2NjdXJpbmcgd2hpbGUgbG9hZCBkZWZlcnJpbmcgaXMgYWN0aXZl LAorICAgICAgICAvLyBzbyBzdXNwZW5kIHRoZW0gbm93LgorICAgICAgICBmb3IgKEZyYW1lKiBm cmFtZSA9IG1haW5GcmFtZSgpOyBmcmFtZTsgZnJhbWUgPSBmcmFtZS0+dHJlZSgpLT50cmF2ZXJz ZU5leHQoKSkKKyAgICAgICAgICAgIGZyYW1lLT5kb2N1bWVudCgpLT5zdXNwZW5kU2NoZWR1bGVk VGFza3MoQWN0aXZlRE9NT2JqZWN0OjpXaWxsRGVmZXJMb2FkaW5nKTsKKyAgICB9CiAKICAgICBt X2RlZmVyc0xvYWRpbmcgPSBkZWZlcnM7Ci0gICAgZm9yIChGcmFtZSogZnJhbWUgPSBtYWluRnJh bWUoKTsgZnJhbWU7IGZyYW1lID0gZnJhbWUtPnRyZWUoKS0+dHJhdmVyc2VOZXh0KCkpCi0gICAg ICAgIGZyYW1lLT5sb2FkZXIoKS0+c2V0RGVmZXJzTG9hZGluZyhkZWZlcnMpOworCisgICAgaWYg KG1fc2V0dGluZ3MtPmxvYWREZWZlcnJpbmdFbmFibGVkKCkpIHsKKyAgICAgICAgZm9yIChGcmFt ZSogZnJhbWUgPSBtYWluRnJhbWUoKTsgZnJhbWU7IGZyYW1lID0gZnJhbWUtPnRyZWUoKS0+dHJh dmVyc2VOZXh0KCkpCisgICAgICAgICAgICBmcmFtZS0+bG9hZGVyKCktPnNldERlZmVyc0xvYWRp bmcoZGVmZXJzKTsKKyAgICB9CisgICAgCisgICAgaWYgKCFkZWZlcnMpIHsKKyAgICAgICAgZm9y IChGcmFtZSogZnJhbWUgPSBtYWluRnJhbWUoKTsgZnJhbWU7IGZyYW1lID0gZnJhbWUtPnRyZWUo KS0+dHJhdmVyc2VOZXh0KCkpCisgICAgICAgICAgICBmcmFtZS0+ZG9jdW1lbnQoKS0+cmVzdW1l U2NoZWR1bGVkVGFza3MoKTsKKyAgICB9CiB9CiAKIHZvaWQgUGFnZTo6Y2xlYXJVbmRvUmVkb09w ZXJhdGlvbnMoKQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGFnZS9QYWdlR3JvdXBMb2Fk RGVmZXJyZXIuY3BwIGIvU291cmNlL1dlYkNvcmUvcGFnZS9QYWdlR3JvdXBMb2FkRGVmZXJyZXIu Y3BwCmluZGV4IDc1MWE3OTguLjEwNWVhN2MgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3Bh Z2UvUGFnZUdyb3VwTG9hZERlZmVycmVyLmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9wYWdlL1Bh Z2VHcm91cExvYWREZWZlcnJlci5jcHAKQEAgLTQwLDE2ICs0MCw4IEBAIFBhZ2VHcm91cExvYWRE ZWZlcnJlcjo6UGFnZUdyb3VwTG9hZERlZmVycmVyKFBhZ2UqIHBhZ2UsIGJvb2wgZGVmZXJTZWxm KQogICAgIEhhc2hTZXQ8UGFnZSo+Ojpjb25zdF9pdGVyYXRvciBlbmQgPSBwYWdlcy5lbmQoKTsK ICAgICBmb3IgKEhhc2hTZXQ8UGFnZSo+Ojpjb25zdF9pdGVyYXRvciBpdCA9IHBhZ2VzLmJlZ2lu KCk7IGl0ICE9IGVuZDsgKytpdCkgewogICAgICAgICBQYWdlKiBvdGhlclBhZ2UgPSAqaXQ7Ci0g ICAgICAgIGlmICgoZGVmZXJTZWxmIHx8IG90aGVyUGFnZSAhPSBwYWdlKSkgewotICAgICAgICAg ICAgaWYgKCFvdGhlclBhZ2UtPmRlZmVyc0xvYWRpbmcoKSkgewotICAgICAgICAgICAgICAgIG1f ZGVmZXJyZWRGcmFtZXMuYXBwZW5kKG90aGVyUGFnZS0+bWFpbkZyYW1lKCkpOwotCi0gICAgICAg ICAgICAgICAgLy8gVGhpcyBjb2RlIGlzIG5vdCBsb2dpY2FsbHkgcGFydCBvZiBsb2FkIGRlZmVy cmluZywgYnV0IHdlIGRvIG5vdCB3YW50IEpTIGNvZGUgZXhlY3V0ZWQgYmVuZWF0aCBtb2RhbAot ICAgICAgICAgICAgICAgIC8vIHdpbmRvd3Mgb3Igc2hlZXRzLCB3aGljaCBpcyBleGFjdGx5IHdo ZW4gUGFnZUdyb3VwTG9hZERlZmVycmVyIGlzIHVzZWQuCi0gICAgICAgICAgICAgICAgZm9yIChG cmFtZSogZnJhbWUgPSBvdGhlclBhZ2UtPm1haW5GcmFtZSgpOyBmcmFtZTsgZnJhbWUgPSBmcmFt ZS0+dHJlZSgpLT50cmF2ZXJzZU5leHQoKSkKLSAgICAgICAgICAgICAgICAgICAgZnJhbWUtPmRv Y3VtZW50KCktPnN1c3BlbmRTY2hlZHVsZWRUYXNrcyhBY3RpdmVET01PYmplY3Q6OldpbGxEZWZl ckxvYWRpbmcpOwotICAgICAgICAgICAgfQotICAgICAgICB9CisgICAgICAgIGlmICgoZGVmZXJT ZWxmIHx8IG90aGVyUGFnZSAhPSBwYWdlKSAmJiAhb3RoZXJQYWdlLT5kZWZlcnNMb2FkaW5nKCkp CisgICAgICAgICAgICBtX2RlZmVycmVkRnJhbWVzLmFwcGVuZChvdGhlclBhZ2UtPm1haW5GcmFt ZSgpKTsKICAgICB9CiAKICAgICBzaXplX3QgY291bnQgPSBtX2RlZmVycmVkRnJhbWVzLnNpemUo KTsKQEAgLTYxLDEyICs1Myw4IEBAIFBhZ2VHcm91cExvYWREZWZlcnJlcjo6UGFnZUdyb3VwTG9h ZERlZmVycmVyKFBhZ2UqIHBhZ2UsIGJvb2wgZGVmZXJTZWxmKQogUGFnZUdyb3VwTG9hZERlZmVy cmVyOjp+UGFnZUdyb3VwTG9hZERlZmVycmVyKCkKIHsKICAgICBmb3IgKHNpemVfdCBpID0gMDsg aSA8IG1fZGVmZXJyZWRGcmFtZXMuc2l6ZSgpOyArK2kpIHsKLSAgICAgICAgaWYgKFBhZ2UqIHBh Z2UgPSBtX2RlZmVycmVkRnJhbWVzW2ldLT5wYWdlKCkpIHsKKyAgICAgICAgaWYgKFBhZ2UqIHBh Z2UgPSBtX2RlZmVycmVkRnJhbWVzW2ldLT5wYWdlKCkpCiAgICAgICAgICAgICBwYWdlLT5zZXRE ZWZlcnNMb2FkaW5nKGZhbHNlKTsKLQotICAgICAgICAgICAgZm9yIChGcmFtZSogZnJhbWUgPSBw YWdlLT5tYWluRnJhbWUoKTsgZnJhbWU7IGZyYW1lID0gZnJhbWUtPnRyZWUoKS0+dHJhdmVyc2VO ZXh0KCkpCi0gICAgICAgICAgICAgICAgZnJhbWUtPmRvY3VtZW50KCktPnJlc3VtZVNjaGVkdWxl ZFRhc2tzKCk7Ci0gICAgICAgIH0KICAgICB9CiB9CiAK