172167 2017-05-16 06:39:16 -0700 [Threaded Compositor] SHOULD NEVER BE REACHED in WebKit::CompositingRunLoop::updateCompleted 2017-06-13 17:10:38 -0700 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build Unspecified Unspecified REOPENED https://bugs.webkit.org/show_bug.cgi?id=171336 https://bugs.webkit.org/show_bug.cgi?id=172892 Gtk, LayoutTestFailure P2 Normal --- 1 cgarcia webkit-unassigned bugs-noreply cturner mcatanzaro zan oldest_to_newest 1309117 0 cgarcia 2017-05-16 06:39:16 -0700 This is still happening, even after r216182, less often but still happens. There are two conditions in which this can happen: - Again in force repaint. r216182 fixed the case of force repaint called when update state is completed, but it can also crash if update state is inProgress or PendingAfterCompletion when m_coordinateUpdateCompletionWithClient is true. - When the threaded compositor is invalidated right after renderLayerTree() starts, but before it finishes. I'll submit a patch to fix this. 1309119 1 310260 cgarcia 2017-05-16 06:49:41 -0700 Created attachment 310260 Patch 1309120 2 cgarcia 2017-05-16 06:54:23 -0700 I think this patch also fixes test imported/blink/compositing/layer-creation/incremental-destruction.html that is currently timing out in the release bot. 1309164 3 310260 mcatanzaro 2017-05-16 10:16:40 -0700 Comment on attachment 310260 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=310260&action=review > Source/WebKit2/ChangeLog:23 > + (WebKit::ThreadedDisplayRefreshMonitor::dispatchDisplayRefreshCallback): Return early if the montior has been invalidated. monitor 1309492 4 cgarcia 2017-05-17 00:16:13 -0700 (In reply to Carlos Garcia Campos from comment #2) > I think this patch also fixes test > imported/blink/compositing/layer-creation/incremental-destruction.html that > is currently timing out in the release bot. And maybe this also fixes bug #172027, it could be similar to the timeout of imported/blink/compositing/layer-creation/incremental-destruction.html, because of a force repaint the compositing run loop gets stalled in PendingAfterCompletion state because the completion never happens. 1309493 5 cgarcia 2017-05-17 00:19:07 -0700 Committed r216970: <http://trac.webkit.org/changeset/216970> 1309524 6 310260 zan 2017-05-17 02:59:15 -0700 Comment on attachment 310260 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=310260&action=review > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:266 > - sceneUpdateFinished(); > + if (m_scene->isActive()) > + sceneUpdateFinished(); How can this occur? renderLayerTree() returns early at the beginning if the scene is not active. If it is active, the function then executes serially, which should make it impossible for any task to be scheduled on this thread that would make the scene inactive. > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 > + // Do not change m_coordinateUpdateCompletionWithClient while in force repaint. > + if (m_inForceRepaint) > + return; m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well. 1309527 7 cgarcia 2017-05-17 03:03:01 -0700 (In reply to Zan Dobersek from comment #6) > Comment on attachment 310260 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=310260&action=review > > > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:266 > > - sceneUpdateFinished(); > > + if (m_scene->isActive()) > > + sceneUpdateFinished(); > > How can this occur? renderLayerTree() returns early at the beginning if the > scene is not active. If it is active, the function then executes serially, > which should make it impossible for any task to be scheduled on this thread > that would make the scene inactive. Because invalidate happens in the main thread. > > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 > > + // Do not change m_coordinateUpdateCompletionWithClient while in force repaint. > > + if (m_inForceRepaint) > > + return; > > m_coordinateUpdateCompletion should be set here, but to false if > m_inForceRepaint is false as well. That happens, because it doesn't return early. 1309528 8 310260 zan 2017-05-17 03:08:58 -0700 Comment on attachment 310260 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=310260&action=review >>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:266 >>> + sceneUpdateFinished(); >> >> How can this occur? renderLayerTree() returns early at the beginning if the scene is not active. If it is active, the function then executes serially, which should make it impossible for any task to be scheduled on this thread that would make the scene inactive. > > Because invalidate happens in the main thread. That's doing unsafe cross-thread modifications then. >>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 >>> + return; >> >> m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well. > > That happens, because it doesn't return early. I'm saying it should be set regardless of the value of m_inForceRepaint. But if m_inForceRepaint is false, it should be set to false. bool coordinateUpdate = m_inForceRepaint && std::any_of(... 1309539 9 cgarcia 2017-05-17 03:32:38 -0700 (In reply to Zan Dobersek from comment #8) > Comment on attachment 310260 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=310260&action=review > > >>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:266 > >>> + sceneUpdateFinished(); > >> > >> How can this occur? renderLayerTree() returns early at the beginning if the scene is not active. If it is active, the function then executes serially, which should make it impossible for any task to be scheduled on this thread that would make the scene inactive. > > > > Because invalidate happens in the main thread. > > That's doing unsafe cross-thread modifications then. We should probably make m_isActive an Atomic<bool>, yes. > >>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 > >>> + return; > >> > >> m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well. > > > > That happens, because it doesn't return early. > > I'm saying it should be set regardless of the value of m_inForceRepaint. But > if m_inForceRepaint is false, it should be set to false. > > bool coordinateUpdate = m_inForceRepaint && std::any_of(... That's what caused the timeout, and I suspect bug #172027 too. If we change coordinateUpdate for the force repaint, the frame is never completed. If the state is PendingAfterCompletion, we won't process more updates. So, what we do here is handling the force update like it didn't happen, to ensure frame updates continue working as expected. 1309568 10 mcatanzaro 2017-05-17 05:49:12 -0700 Seems like we need to reopen this... 1309578 11 310260 zan 2017-05-17 06:54:24 -0700 Comment on attachment 310260 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=310260&action=review >>>>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 >>>>> + return; >>>> >>>> m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well. >>> >>> That happens, because it doesn't return early. >> >> I'm saying it should be set regardless of the value of m_inForceRepaint. But if m_inForceRepaint is false, it should be set to false. >> >> bool coordinateUpdate = m_inForceRepaint && std::any_of(... > > That's what caused the timeout, and I suspect bug #172027 too. If we change coordinateUpdate for the force repaint, the frame is never completed. If the state is PendingAfterCompletion, we won't process more updates. So, what we do here is handling the force update like it didn't happen, to ensure frame updates continue working as expected. When do you expect a forced updated to be finished? And do you expect the DisplayRefreshMonitor callback to be scheduled for forced updates? You also don't have any guarantee that there is a scene state update pending that would be executed during a forced repaint, meaning m_clientRendersNextFrame isn't necessarily flipped to true, which would end up not scheduling a DisplayRefreshMonitor callback in sceneUpdateFinished() that would complete the update. 1310006 12 cgarcia 2017-05-17 23:44:15 -0700 (In reply to Zan Dobersek from comment #11) > Comment on attachment 310260 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=310260&action=review > > >>>>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292 > >>>>> + return; > >>>> > >>>> m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well. > >>> > >>> That happens, because it doesn't return early. > >> > >> I'm saying it should be set regardless of the value of m_inForceRepaint. But if m_inForceRepaint is false, it should be set to false. > >> > >> bool coordinateUpdate = m_inForceRepaint && std::any_of(... > > > > That's what caused the timeout, and I suspect bug #172027 too. If we change coordinateUpdate for the force repaint, the frame is never completed. If the state is PendingAfterCompletion, we won't process more updates. So, what we do here is handling the force update like it didn't happen, to ensure frame updates continue working as expected. > > When do you expect a forced updated to be finished? And do you expect the > DisplayRefreshMonitor callback to be scheduled for forced updates? > > You also don't have any guarantee that there is a scene state update pending > that would be executed during a forced repaint, meaning > m_clientRendersNextFrame isn't necessarily flipped to true, which would end > up not scheduling a DisplayRefreshMonitor callback in sceneUpdateFinished() > that would complete the update. A fore repaint is always synchronous, it calls renderLayerTree directly so it's not expected to call updateCompleted(). I don't know if we should do anything special with the refresh monitor in that case. These are the situations that can happen when a forceRepaint is scheduled. 1) Previous update is complete. If updateCompleted() is called, it will crash in SHOULD NEVER BE REACHED. 2) Previous frame is InProgress and m_coordinateUpdateCompletionWithClient is false. If the frame renderLayerTree happens before the force repaint, then updateCompleted() will be called, so it would be like previous case. If it happens after, the forceRepaint one will not calle updateCompleted() and the InProgress frame will. At some point the scene is committed and the update lambda is called. If the force repaint happens before the update would do nothing, leaving m_coordinateUpdateCompletionWithClient as false. When completeCoordinatedUpdateIfNeeded is called, m_coordinateUpdateCompletionWithClient is still false as expected and updateCompleted() is not called (it was already called once for this frame). 3) Previous frame is InProgress and m_coordinateUpdateCompletionWithClient is true. In this case updateCompleted() won't be called no matter if one renderLayerTree is called before the other. But at some point the scene is committed and the update lambda is called. If the force repaint happens before the update would do nothing, leaving the m_coordinateUpdateCompletionWithClient as true. When completeCoordinatedUpdateIfNeeded is called, m_coordinateUpdateCompletionWithClient is still true as expected and updateCompleted() is called. 4) Previous frame if in PendingAfterCompletion. So this is like 2) or 3) but another frame has been scheduled and should be fired after previous one finishes. 1) was causing SHOULD NEVER BE REACHED, and it was fixed in r216182. In 2) and 3) the value of m_coordinateUpdateCompletionWithClient might be changed in an unexpected way by the forceRepaint commit, causing updateCompleted() to be called twice and then crashing in SHOULD NEVER BE REACHED. This was fixed by this bug. In 4) the value of m_coordinateUpdateCompletionWithClient might be changed in an unexpected way by the forceRepaint commit, causing updateCompleted() to never be called, causing the timeout in imported/blink/compositing/layer-creation/incremental-destruction.html and maybe bug #172027 too. This was fixed by this bug. Maybe there are still cases not considered or we need to do something else with the refresh monitor, but at least after r216970 all tests crashing in SHOULD NEVER BE REACHED stopped crashing, test imported/blink/compositing/layer-creation/incremental-destruction.html is no longer timing out, and Adri can use github again. I admit I don't completely understand the whole frame update mechanism and refresh monitor, but it's a lot more stable now. Let's improve it on top of this if needed. 1318808 13 cturner 2017-06-13 14:01:08 -0700 I'm still hitting case 1). I can pretty reliably trigger it by watching any YouTube video with Epiphany built against r218095. It's non-deterministic if you just let videos play, but I found that interacting with any of the controls is a sure fire way of getting this backtrace (among others unfortunately, but you always get one :)) The m_updateState is Completed when I enter the updateCompleted(): SHOULD NEVER BE REACHED ../../Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp(188) : void WebKit::CompositingRunLoop::updateCompleted() 1 0x7f0dc5e50818 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x1e) [0x7f0dc5e50818] 2 0x7f0dcd8443a8 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::CompositingRunLoop::updateCompleted()+0xe4) [0x7f0dcd8443a8] 3 0x7f0dcd849d6a /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCompositor::sceneUpdateFinished()+0xb8) [0x7f0dcd849d6a] 4 0x7f0dcd84a33f /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCompositor::frameComplete()+0x45) [0x7f0dcd84a33f] 5 0x7f0dcda48d06 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCoordinatedLayerTreeHost::frameComplete()+0x26) [0x7f0dcda48d06] 6 0x7f0dcda50c15 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::AcceleratedSurfaceX11::didRenderFrame()+0x27) [0x7f0dcda50c15] 7 0x7f0dcda48e55 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCoordinatedLayerTreeHost::didRenderFrame()+0x43) [0x7f0dcda48e55] 8 0x7f0dcda49bdc /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCoordinatedLayerTreeHost::CompositorClient::didRenderFrame()+0x1c) [0x7f0dcda49bdc] 9 0x7f0dcd849c8e /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::ThreadedCompositor::renderLayerTree()+0x372) [0x7f0dcd849c8e] 10 0x7f0dcd8489cd /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(+0x64e59cd) [0x7f0dcd8489cd] 11 0x7f0dcd84c916 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(+0x64e9916) [0x7f0dcd84c916] 12 0x357abca /home/charlie/jhbuild/install/libexec/webkit2gtk-4.0/WebKitWebProcess(std::function<void ()>::operator()() const+0x32) [0x357abca] 13 0x7f0dcd8443c8 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WebKit::CompositingRunLoop::updateTimerFired()+0x1c) [0x7f0dcd8443c8] 14 0x7f0dcd847e58 /home/charlie/jhbuild/install/lib/libwebkit2gtk-4.0.so.37(WTF::RunLoop::Timer<WebKit::CompositingRunLoop>::fired()+0x66) [0x7f0dcd847e58] 15 0x7f0dc5ebeaf1 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a78af1) [0x7f0dc5ebeaf1] 16 0x7f0dc5ebeb2d /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a78b2d) [0x7f0dc5ebeb2d] 17 0x7f0dc5ebe1a2 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a781a2) [0x7f0dc5ebe1a2] 18 0x7f0dc5ebe1d1 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a781d1) [0x7f0dc5ebe1d1] 19 0x7f0dc0c59dca /home/charlie/jhbuild/install/lib/libglib-2.0.so.0(g_main_context_dispatch+0x15a) [0x7f0dc0c59dca] 20 0x7f0dc0c5a170 /home/charlie/jhbuild/install/lib/libglib-2.0.so.0(+0x4b170) [0x7f0dc0c5a170] 21 0x7f0dc0c5a492 /home/charlie/jhbuild/install/lib/libglib-2.0.so.0(g_main_loop_run+0xc2) [0x7f0dc0c5a492] 22 0x7f0dc5ebe738 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(WTF::RunLoop::run()+0xba) [0x7f0dc5ebe738] 23 0x7f0dc5ebc20e /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a7620e) [0x7f0dc5ebc20e] 24 0x7f0dc5ebdc82 /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a77c82) [0x7f0dc5ebdc82] 25 0x351a3cf /home/charlie/jhbuild/install/libexec/webkit2gtk-4.0/WebKitWebProcess(WTF::Function<void ()>::operator()() const+0x37) [0x351a3cf] 26 0x7f0dc5e74e9e /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a2ee9e) [0x7f0dc5e74e9e] 27 0x7f0dc5eba77b /home/charlie/jhbuild/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2a7477b) [0x7f0dc5eba77b] 28 0x7f0dbecfa6ba /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f0dbecfa6ba] 29 0x7f0dbdd7382d /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f0dbdd7382d] 1318909 14 cturner 2017-06-13 17:10:38 -0700 FWIW, I did test the change to have m_isActive an atomic bool, but that didn't slow down the frequency of crashing much. 310260 2017-05-16 06:49:41 -0700 2017-05-16 10:16:40 -0700 Patch wk2-tc-crash.diff text/plain 4668 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQyL0No YW5nZUxvZwppbmRleCAwMzllYjJlNmQxNy4uNjRiOTlkNTNjNmMgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJLaXQyL0NoYW5nZUxvZworKysgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKQEAgLTEs NSArMSwyOSBAQAogMjAxNy0wNS0xNiAgQ2FybG9zIEdhcmNpYSBDYW1wb3MgIDxjZ2FyY2lhQGln YWxpYS5jb20+CiAKKyAgICAgICAgW1RocmVhZGVkIENvbXBvc2l0b3JdIFNIT1VMRCBORVZFUiBC RSBSRUFDSEVEIGluIFdlYktpdDo6Q29tcG9zaXRpbmdSdW5Mb29wOjp1cGRhdGVDb21wbGV0ZWQK KyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE3MjE2Nwor CisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFRoaXMgaXMg c3RpbGwgaGFwcGVuaW5nLCBldmVuIGFmdGVyIHIyMTYxODIsIGxlc3Mgb2Z0ZW4gYnV0IHN0aWxs IGhhcHBlbnMuIFRoZXJlIGFyZSB0d28gY29uZGl0aW9ucyBpbiB3aGljaAorICAgICAgICB0aGlz IGNhbiBoYXBwZW46CisKKyAgICAgICAgIC0gQWdhaW4gaW4gZm9yY2UgcmVwYWludC4gcjIxNjE4 MiBmaXhlZCB0aGUgY2FzZSBvZiBmb3JjZSByZXBhaW50IGNhbGxlZCB3aGVuIHVwZGF0ZSBzdGF0 ZSBpcyBjb21wbGV0ZWQsIGJ1dCBpdAorICAgICAgICAgICBjYW4gYWxzbyBjcmFzaCBpZiB1cGRh dGUgc3RhdGUgaXMgaW5Qcm9ncmVzcyBvciBQZW5kaW5nQWZ0ZXJDb21wbGV0aW9uIHdoZW4gbV9j b29yZGluYXRlVXBkYXRlQ29tcGxldGlvbldpdGhDbGllbnQKKyAgICAgICAgICAgaXMgdHJ1ZS4K KyAgICAgICAgIC0gV2hlbiB0aGUgdGhyZWFkZWQgY29tcG9zaXRvciBpcyBpbnZhbGlkYXRlZCBy aWdodCBhZnRlciByZW5kZXJMYXllclRyZWUoKSBzdGFydHMsIGJ1dCBiZWZvcmUgaXQgZmluaXNo ZXMuCisKKyAgICAgICAgKiBTaGFyZWQvQ29vcmRpbmF0ZWRHcmFwaGljcy90aHJlYWRlZGNvbXBv c2l0b3IvVGhyZWFkZWRDb21wb3NpdG9yLmNwcDoKKyAgICAgICAgKFdlYktpdDo6VGhyZWFkZWRD b21wb3NpdG9yOjppbnZhbGlkYXRlKTogSW52YWxpZGF0ZSB0aGUgcmVmcmVzaCBtb25pdG9yIHJp Z2h0IGFmdGVyIHN0b3BwaW5nIHVwZGF0ZXMgaW4gdGhlCisgICAgICAgIGNvbXBvc2l0aW5nIHJ1 biBsb29wIHRvIGVuc3VyZSBubyBtb3JlIHVwZGF0ZXMgYXJlIHNjaGVkdWxlZC4KKyAgICAgICAg KFdlYktpdDo6VGhyZWFkZWRDb21wb3NpdG9yOjpyZW5kZXJMYXllclRyZWUpOiBDaGVjayB0aGUg c2NlbmUgaXMgc3RpbGwgYWN0aXZlIGJlZm9yZSBjYWxsaW5nIHNjZW5lVXBkYXRlRmluaXNoZWQo KS4KKyAgICAgICAgKFdlYktpdDo6VGhyZWFkZWRDb21wb3NpdG9yOjp1cGRhdGVTY2VuZVN0YXRl KTogRG8gbm90IHVwZGF0ZSBtX2Nvb3JkaW5hdGVVcGRhdGVDb21wbGV0aW9uV2l0aENsaWVudCB3 aGVuIGluCisgICAgICAgIGZvcmNlIHJlcGFpbnQuCisgICAgICAgICogU2hhcmVkL0Nvb3JkaW5h dGVkR3JhcGhpY3MvdGhyZWFkZWRjb21wb3NpdG9yL1RocmVhZGVkRGlzcGxheVJlZnJlc2hNb25p dG9yLmNwcDoKKyAgICAgICAgKFdlYktpdDo6VGhyZWFkZWREaXNwbGF5UmVmcmVzaE1vbml0b3I6 OmRpc3BhdGNoRGlzcGxheVJlZnJlc2hDYWxsYmFjayk6IFJldHVybiBlYXJseSBpZiB0aGUgbW9u dGlvciBoYXMgYmVlbiBpbnZhbGlkYXRlZC4KKworMjAxNy0wNS0xNiAgQ2FybG9zIEdhcmNpYSBD YW1wb3MgIDxjZ2FyY2lhQGlnYWxpYS5jb20+CisKICAgICAgICAgVW5yZXZpZXdlZC4gUmV2ZXJ0 IGNoYW5nZSBjb21taXR0ZWQgYnkgbWlzdGFrbGUgaW4gcjIxNjkyMi4KIAogICAgICAgICAqIFNo YXJlZC9Db29yZGluYXRlZEdyYXBoaWNzL3RocmVhZGVkY29tcG9zaXRvci9UaHJlYWRlZENvbXBv c2l0b3IuY3BwOgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvU2hhcmVkL0Nvb3JkaW5hdGVk R3JhcGhpY3MvdGhyZWFkZWRjb21wb3NpdG9yL1RocmVhZGVkQ29tcG9zaXRvci5jcHAgYi9Tb3Vy Y2UvV2ViS2l0Mi9TaGFyZWQvQ29vcmRpbmF0ZWRHcmFwaGljcy90aHJlYWRlZGNvbXBvc2l0b3Iv VGhyZWFkZWRDb21wb3NpdG9yLmNwcAppbmRleCBjMDhjYmZkN2Y5OS4uZTU4ZTE5M2E5ZmQgMTAw NjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQyL1NoYXJlZC9Db29yZGluYXRlZEdyYXBoaWNzL3RocmVh ZGVkY29tcG9zaXRvci9UaHJlYWRlZENvbXBvc2l0b3IuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQy L1NoYXJlZC9Db29yZGluYXRlZEdyYXBoaWNzL3RocmVhZGVkY29tcG9zaXRvci9UaHJlYWRlZENv bXBvc2l0b3IuY3BwCkBAIC0xMjQsNiArMTI0LDkgQEAgdm9pZCBUaHJlYWRlZENvbXBvc2l0b3I6 OmludmFsaWRhdGUoKQogewogICAgIG1fc2NlbmUtPmRldGFjaCgpOwogICAgIG1fY29tcG9zaXRp bmdSdW5Mb29wLT5zdG9wVXBkYXRlcygpOworI2lmIFVTRShSRVFVRVNUX0FOSU1BVElPTl9GUkFN RV9ESVNQTEFZX01PTklUT1IpCisgICAgbV9kaXNwbGF5UmVmcmVzaE1vbml0b3ItPmludmFsaWRh dGUoKTsKKyNlbmRpZgogICAgIG1fY29tcG9zaXRpbmdSdW5Mb29wLT5wZXJmb3JtVGFza1N5bmMo W3RoaXMsIHByb3RlY3RlZFRoaXMgPSBtYWtlUmVmKCp0aGlzKV0gewogICAgICAgICBtX3NjZW5l LT5wdXJnZUdMUmVzb3VyY2VzKCk7CiAgICAgICAgIG1fY29udGV4dCA9IG51bGxwdHI7CkBAIC0x MzIsMTMgKzEzNSw3IEBAIHZvaWQgVGhyZWFkZWRDb21wb3NpdG9yOjppbnZhbGlkYXRlKCkKICNl bmRpZgogICAgICAgICBtX3NjZW5lID0gbnVsbHB0cjsKICAgICB9KTsKLSNpZiBVU0UoUkVRVUVT VF9BTklNQVRJT05fRlJBTUVfRElTUExBWV9NT05JVE9SKQotICAgIG1fZGlzcGxheVJlZnJlc2hN b25pdG9yLT5pbnZhbGlkYXRlKCk7Ci0jZW5kaWYKICAgICBtX2NvbXBvc2l0aW5nUnVuTG9vcCA9 IG51bGxwdHI7Ci0jaWYgVVNFKFJFUVVFU1RfQU5JTUFUSU9OX0ZSQU1FX0RJU1BMQVlfTU9OSVRP UikKLSAgICBtX2Rpc3BsYXlSZWZyZXNoTW9uaXRvci0+aW52YWxpZGF0ZSgpOwotI2VuZGlmCiB9 CiAKIHZvaWQgVGhyZWFkZWRDb21wb3NpdG9yOjpzZXROYXRpdmVTdXJmYWNlSGFuZGxlRm9yQ29t cG9zaXRpbmcodWludDY0X3QgaGFuZGxlKQpAQCAtMjY1LDcgKzI2Miw4IEBAIHZvaWQgVGhyZWFk ZWRDb21wb3NpdG9yOjpyZW5kZXJMYXllclRyZWUoKQogI2VuZGlmCiAKICNpZiBQTEFURk9STShH VEspCi0gICAgc2NlbmVVcGRhdGVGaW5pc2hlZCgpOworICAgIGlmIChtX3NjZW5lLT5pc0FjdGl2 ZSgpKQorICAgICAgICBzY2VuZVVwZGF0ZUZpbmlzaGVkKCk7CiAjZW5kaWYKIH0KIApAQCAtMjg5 LDYgKzI4Nyw5IEBAIHZvaWQgVGhyZWFkZWRDb21wb3NpdG9yOjp1cGRhdGVTY2VuZVN0YXRlKGNv bnN0IENvb3JkaW5hdGVkR3JhcGhpY3NTdGF0ZSYgc3RhdGUpCiAgICAgICAgIHNjZW5lLT5jb21t aXRTY2VuZVN0YXRlKHN0YXRlKTsKIAogICAgICAgICBtX2NsaWVudFJlbmRlcnNOZXh0RnJhbWUu c3RvcmUodHJ1ZSk7CisgICAgICAgIC8vIERvIG5vdCBjaGFuZ2UgbV9jb29yZGluYXRlVXBkYXRl Q29tcGxldGlvbldpdGhDbGllbnQgd2hpbGUgaW4gZm9yY2UgcmVwYWludC4KKyAgICAgICAgaWYg KG1faW5Gb3JjZVJlcGFpbnQpCisgICAgICAgICAgICByZXR1cm47CiAgICAgICAgIGJvb2wgY29v cmRpbmF0ZVVwZGF0ZSA9IHN0ZDo6YW55X29mKHN0YXRlLmxheWVyc1RvVXBkYXRlLmJlZ2luKCks IHN0YXRlLmxheWVyc1RvVXBkYXRlLmVuZCgpLAogICAgICAgICAgICAgW10oY29uc3Qgc3RkOjpw YWlyPENvb3JkaW5hdGVkTGF5ZXJJRCwgQ29vcmRpbmF0ZWRHcmFwaGljc0xheWVyU3RhdGU+JiBp dCkgewogICAgICAgICAgICAgICAgIHJldHVybiBpdC5zZWNvbmQucGxhdGZvcm1MYXllckNoYW5n ZWQgfHwgaXQuc2Vjb25kLnBsYXRmb3JtTGF5ZXJVcGRhdGVkOwpkaWZmIC0tZ2l0IGEvU291cmNl L1dlYktpdDIvU2hhcmVkL0Nvb3JkaW5hdGVkR3JhcGhpY3MvdGhyZWFkZWRjb21wb3NpdG9yL1Ro cmVhZGVkRGlzcGxheVJlZnJlc2hNb25pdG9yLmNwcCBiL1NvdXJjZS9XZWJLaXQyL1NoYXJlZC9D b29yZGluYXRlZEdyYXBoaWNzL3RocmVhZGVkY29tcG9zaXRvci9UaHJlYWRlZERpc3BsYXlSZWZy ZXNoTW9uaXRvci5jcHAKaW5kZXggNzM0ODcwOTU4YTQuLmJjMzFiYTg1MmE3IDEwMDY0NAotLS0g YS9Tb3VyY2UvV2ViS2l0Mi9TaGFyZWQvQ29vcmRpbmF0ZWRHcmFwaGljcy90aHJlYWRlZGNvbXBv c2l0b3IvVGhyZWFkZWREaXNwbGF5UmVmcmVzaE1vbml0b3IuY3BwCisrKyBiL1NvdXJjZS9XZWJL aXQyL1NoYXJlZC9Db29yZGluYXRlZEdyYXBoaWNzL3RocmVhZGVkY29tcG9zaXRvci9UaHJlYWRl ZERpc3BsYXlSZWZyZXNoTW9uaXRvci5jcHAKQEAgLTY2LDYgKzY2LDggQEAgYm9vbCBUaHJlYWRl ZERpc3BsYXlSZWZyZXNoTW9uaXRvcjo6cmVxdWlyZXNEaXNwbGF5UmVmcmVzaENhbGxiYWNrKCkK IAogdm9pZCBUaHJlYWRlZERpc3BsYXlSZWZyZXNoTW9uaXRvcjo6ZGlzcGF0Y2hEaXNwbGF5UmVm cmVzaENhbGxiYWNrKCkKIHsKKyAgICBpZiAoIW1fY29tcG9zaXRvcikKKyAgICAgICAgcmV0dXJu OwogICAgIG1fZGlzcGxheVJlZnJlc2hUaW1lci5zdGFydE9uZVNob3QoMCk7CiB9CiAK