185242 2018-05-03 01:49:17 -0700 [MSE][GStreamer] Delete properly the stream from the WebKitMediaSource 2018-05-17 05:04:56 -0700 1 1 1 Unclassified WebKit Media WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 185277 1 bandou.yacine webkit-unassigned aboya calvaris commit-queue eocanha olivier.blin webkit-bug-importer oldest_to_newest 1420057 0 bandou.yacine 2018-05-03 01:49:17 -0700 When the sourceBuffer is removed from mediasource, the appropriate stream is not properly deleted from WebKitMediaSource. The Appsrc and the Parser didn't removed from the WebKitMediaSource bin element. 1420079 1 eocanha 2018-05-03 03:42:58 -0700 Is this SourceBuffer removal happening at any time point different from the player destruction? Specifically, do you have any use case where the player keeps being used after a single SourceBuffer is removed? This would mean that actual removal of the appsrc and parser elements on demand should be taken into account (currently isn't, as you pointed out). Otherwise, the WebKitMediaSrc bin destruction should automatically trigger the destruction of the appsrc and parser elements. I don't remember the implications now, but probably the implementation is like this (removal deferred to bin destruction) in order to avoid transient states caused by the on-demand removal, which might complicate WebKitMediaSrc management without need in a moment where its final destruction is about to happen. 1420102 2 bandou.yacine 2018-05-03 06:30:27 -0700 (In reply to Enrique Ocaña from comment #1) > Is this SourceBuffer removal happening at any time point different from the > player destruction? Specifically, do you have any use case where the player > keeps being used after a single SourceBuffer is removed? This would mean > that actual removal of the appsrc and parser elements on demand should be > taken into account (currently isn't, as you pointed out). > > Otherwise, the WebKitMediaSrc bin destruction should automatically trigger > the destruction of the appsrc and parser elements. I don't remember the > implications now, but probably the implementation is like this (removal > deferred to bin destruction) in order to avoid transient states caused by > the on-demand removal, which might complicate WebKitMediaSrc management > without need in a moment where its final destruction is about to happen. Currently when there is an error in playback as no decryption key in the decryptor the implementation calls HTMLMediaElement::noneSupported() wich detaches the MediaSource from MediaElement then it removes all its SourceBuffers. When we remove SourceBuffer the function webKitMediaSrcFreeStream(m_webKitMediaSrc.get(), stream) is called via PlaybackPipeline::removeSourceBuffer(sourceBufferPrivate). Then the PlayerPrivate catch "source-setup" signal and calls MediaPlayerPrivateGStreamerMSE::sourceSetup wich calls setPrivateAndOpen via MediaSourceGStreamer::open. The function setPrivateAndOpen tries to call the instance of MediaElement wich is already detached from MediaSource, thus causing a crash. When we properly delete the Stream by removing the appropriate appsrc and parser from the bin, the pipeline never send the "source-setup" signal. Otherwise, I think the function webKitMediaSrcFreeStream should delete the Stream correctly without having this crash. 1420505 3 339498 bandou.yacine 2018-05-03 18:00:56 -0700 Created attachment 339498 Patch 1420593 4 339498 calvaris 2018-05-04 01:03:19 -0700 Comment on attachment 339498 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=339498&action=review I see this patch is ok though I prefer Enrique to give the final go. > Source/WebCore/ChangeLog:10 > + The Appsrc and the Parser didn't removed from the WebKitMediaSource bin element. This sentence doesn't make too much sense to me. > Source/WebCore/ChangeLog:12 > + This patch avoid the regression of r231089, see https://bugs.webkit.org/show_bug.cgi?id=185071 avoids. 1420599 5 339498 eocanha 2018-05-04 02:25:07 -0700 Comment on attachment 339498 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=339498&action=review > Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:543 > + source->priv->numberOfAudioStreams--; These changes in numberOf{Audio,Video,Text}Streams must be protected by GST_OBJECT_{LOCK,UNLOCK}(webKitMediaSrc) (webKitMediaSrc is "source" in webKitMediaSrcFreeStream()). See PlaybackPipeline::attachTrack() and ::reattachTrack(). In order to avoid taking both the webKitMediaSrc and stream locks at the same time, split the code in two pieces, duplicating the "if (stream->type != WebCore::Invalid) {" block and its inner switch statement. The first "if" block would be protected by GST_OBJECT{LOCK,UNLOCK}(webKitMediaSrc) and would just change numberOf{Audio,Video,Text}Streams as quickly as possible. The second "if" block would be the original one, which locks on streamLock. 1420611 6 339534 bandou.yacine 2018-05-04 03:17:45 -0700 Created attachment 339534 Patch 1420617 7 339534 eocanha 2018-05-04 04:17:03 -0700 Comment on attachment 339534 Patch Looks good. Let's wait for Xabier to +r it. 1420635 8 339534 commit-queue 2018-05-04 06:26:18 -0700 Comment on attachment 339534 Patch Clearing flags on attachment: 339534 Committed r231351: <https://trac.webkit.org/changeset/231351> 1420636 9 commit-queue 2018-05-04 06:26:20 -0700 All reviewed patches have been landed. Closing bug. 1420637 10 webkit-bug-importer 2018-05-04 06:27:21 -0700 <rdar://problem/39974810> 1424292 11 339534 aboya 2018-05-16 05:03:47 -0700 Comment on attachment 339534 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=339534&action=review > Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:516 > + gst_element_set_state(stream->appsrc, GST_STATE_NULL); This will deadlock whenever the streaming thread is waiting for some action that requires WebKit intervention. Note that: a) Setting a source element state to NULL deactivates its pad and therefore attempts to tear down its streaming thread. b) Tearing down a streaming thread is a stream-synchronized operation. The streaming thread is shared with other elements downstream. This means that we need to wait until no buffer or (stream synchronized) event is traveling through this stream. c) A traveling buffer may be blocked waiting for something. For instance, usually the stream ends at the sinkpad of a queue element (the srcpad of the queue element starts a separate streaming thread, so for threading purposes that's separate stream). If the queue is full and won't gain any space until WebKit's main thread performs some action you've got yourself in a catch 22, deadlock. This is what is causing YTTV 18. MediaElementEvents to deadlock after this patch. Note that even though the test finishes when WebKit reports playback has ended, several seconds worth of frames are still queued in the playback pipeline because of a change of duration to a shorter value. The pipeline is set to PAUSED when the shorter duration is reached, so those extra frames are not played, but still try to continue travelling through the pipeline. When the sink element receives a frame in this PAUSED state it has to wait for a state change to PLAYING before doing anything with it (see gst_base_sink_wait_preroll()). This blocks the streaming thread containing the sink. Streaming threads upstream still continue pushing buffers for some time until the queue becomes full, then get blocked as well. Summarizing: in order to tear down the source element you need to tear down its streaming thread. In order to tear down the streaming thread you need to wait for the current flowing buffer to complete its journey in this streaming thread, but that won't happen until the queue at the end of this stream has available space and therefore stops blocking the thread. The queue won't have available space until the sink is set to PLAYING or the pipeline is flushed. That won't ever happen (moreso when the main thread is waiting), therefore you've got a deadlock. 1424587 12 bandou.yacine 2018-05-16 19:52:28 -0700 (In reply to Alicia Boya García from comment #11) > Comment on attachment 339534 [details] > Patch > > > Summarizing: in order to tear down the source element you need to tear down > its streaming thread. In order to tear down the streaming thread you need to > wait for the current flowing buffer to complete its journey in this > streaming thread, but that won't happen until the queue at the end of this > stream has available space and therefore stops blocking the thread. The > queue won't have available space until the sink is set to PLAYING or the > pipeline is flushed. That won't ever happen (moreso when the main thread is > waiting), therefore you've got a deadlock. I agree with you, when I studied in detail what happen with encrypted-media WPT tests, I saw what you said. For that, I tried to fix it with the patch 185592, but it is a bad solution. After a detailed investigation, I found that, this patch doesn't fix the crash, it just replaces the crash by a blocking. Here is the real root cause of the crash. (-> : calls) 1.When an error occurs in playback pipeline (no decipher key), we receive an error message in MediaPlayerPrivateGStreamer::handleMessage -> MediaPlayerPrivateGStreamer::loadingFailed (MediaPlayer::FormatError). 2.The function loadingFailed -> HTMLMediaElement::mediaPlayerNetworkStateChanged (MediaPlayer::FormatError) -> setNetworkState -> mediaLoadingFailed -> noneSupported go to the point 3 | -> HTMLMediaElement::mediaPlayerReadyStateChanged(MediaPlayer::HaveNothing) -> setReadyState -> updatePlayState() go to the point 5 3.nonSupported -> detachMediaSource -> MediaSource::detachFromElement -> removeSourceBuffer -> MediaSourceGStreamer::removeSourceBuffer -> .. ->PlaybackPipeline::removeSourceBuffer 4.PlaybackPipeline::removeSourceBuffer -> webKitMediaSrcFreeStream . 5.HTMLMediaElement::updatePlayState -> potentiallyPlaying -> stoppedDueToErrors ( This function returns false because (m_readyState >= HAVE_METADATA && m_error) is false, m_readyState equal to HaveNothing ) 6.HTMLMediaElement::updatePlayState -> MediaPlayer::play -> MediaPlayerPrivateGStreamer::play -> changePipelineState (set the pipeline to playing state) 7.WebkitMediaSourceGStreamer sends "source-setup" signal when its state change from Ready to Paused, the signal catched in MediaPlayerPrivateGStreamer::sourceSetupCallback 8.MediaPlayerPrivateGStreamer::sourceSetupCallback -> MediaPlayerPrivateGStreamerMSE::sourceSetup -> MediaSourceGStreamer::open -> MediaSource::setPrivateAndOpen (crash in this function because the mediaSource is detached from mediaElement in the point 3, thus the variable m_mediaElement is null). In the point 5 the function "HTMLMediaElement::stoppedDueToErrors" returns false, because m_readyState equal to HaveNothing and it is not upper than HAVE_METADATA. I think we don't have to set the ReadyState to HaveNothing when an error occurs in pipeline, we should just set NetworkState to error. Here is the my roadmap: 1. I'll push a new patch to remove a part of this patch (185242) which caused the blocking. 2. I'll push an other new patch to fix the crash, this patch just set NetworkState without ReadyState when an error occurs in pipeline. 3. I'll close the bug 185592 as invalid bug. 4. I'll update the patch 185593 to depend on the two new patches. 1424658 13 aboya 2018-05-17 03:14:26 -0700 > 1. I'll push a new patch to remove a part of this patch (185242) which caused the blocking. Is there a reason to keep some parts of this patch? Which ones? 1424659 14 aboya 2018-05-17 03:16:10 -0700 (Notice that, as explained in https://bugs.webkit.org/show_bug.cgi?id=185592#c13, you can't just remove the appsrc and assume the stream is gone). 1424685 15 bandou.yacine 2018-05-17 05:04:56 -0700 (In reply to Alicia Boya García from comment #13) > > 1. I'll push a new patch to remove a part of this patch (185242) which caused the blocking. > > Is there a reason to keep some parts of this patch? Which ones? I keep the part which update the "source->priv->numberOfXXXXStreams" 527 GST_OBJECT_LOCK(source); 528 switch (stream->type) { 529 case WebCore::Audio: 530 source->priv->numberOfAudioStreams--; 531 break; 532 case WebCore::Video: 533 source->priv->numberOfVideoStreams--; 534 break; 535 case WebCore::Text: 536 source->priv->numberOfTextStreams--; 537 break; 538 default: 539 break; 540 } 541 GST_OBJECT_UNLOCK(source); 339498 2018-05-03 18:00:56 -0700 2018-05-04 03:17:40 -0700 Patch bug-185242-20180504030055.patch text/plain 2906 bandou.yacine U3VidmVyc2lvbiBSZXZpc2lvbjogMjMxMDQ0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggZTE4MmIwYThjYjhkN2E4 NmVkNWY1OWE4MTlmNDVmYzU1ZTEwZmQ3ZS4uZmYyNzlmYWZjMmU2YTA1YjFjZDVjYzU2ZGEyNzI2 OGRhZTdmYjgwYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE5IEBACisyMDE4LTA1LTAzICBZYWNp bmUgQmFuZG91ICA8eWFjaW5lLmJhbmRvdV9leHRAc29mdGF0aG9tZS5jb20+CisKKyAgICAgICAg W01TRV1bR1N0cmVhbWVyXSBEZWxldGUgcHJvcGVybHkgdGhlIHN0cmVhbSBmcm9tIHRoZSBXZWJL aXRNZWRpYVNvdXJjZQorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j Z2k/aWQ9MTg1MjQyCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg ICAgICAgV2hlbiB0aGUgc291cmNlQnVmZmVyIGlzIHJlbW92ZWQgZnJvbSBtZWRpYXNvdXJjZSwg dGhlIGFwcHJvcHJpYXRlIHN0cmVhbSBpcyBub3QKKyAgICAgICAgcHJvcGVybHkgZGVsZXRlZCBm cm9tIFdlYktpdE1lZGlhU291cmNlLgorICAgICAgICBUaGUgQXBwc3JjIGFuZCB0aGUgUGFyc2Vy IGRpZG4ndCByZW1vdmVkIGZyb20gdGhlIFdlYktpdE1lZGlhU291cmNlIGJpbiBlbGVtZW50Lgor CisgICAgICAgIFRoaXMgcGF0Y2ggYXZvaWQgdGhlIHJlZ3Jlc3Npb24gb2YgcjIzMTA4OSwgc2Vl IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xODUwNzEKKworICAgICAg ICAqIHBsYXRmb3JtL2dyYXBoaWNzL2dzdHJlYW1lci9tc2UvV2ViS2l0TWVkaWFTb3VyY2VHU3Ry ZWFtZXIuY3BwOgorICAgICAgICAod2ViS2l0TWVkaWFTcmNGcmVlU3RyZWFtKToKKwogMjAxOC0w MS0yNCAgWWFjaW5lIEJhbmRvdSAgPHlhY2luZS5iYW5kb3VfZXh0QHNvZnRhdGhvbWUuY29tPgog CiAgICAgICAgIFtFTUVdW0dTdHJlYW1lcl0gTW92ZSB0aGUgZGVjcnlwdG9yIGZyb20gQXBwZW5k UGlwZWxpbmUgdG8gUGxheWJhY2tQaXBlbGluZS4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3Jl L3BsYXRmb3JtL2dyYXBoaWNzL2dzdHJlYW1lci9tc2UvV2ViS2l0TWVkaWFTb3VyY2VHU3RyZWFt ZXIuY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3N0cmVhbWVyL21zZS9X ZWJLaXRNZWRpYVNvdXJjZUdTdHJlYW1lci5jcHAKaW5kZXggZDMyZmJhM2VjZGUwZWIxOWM3NmFj ZDlmZWQ1ZTVjZGQ0ZmRkOTI2YS4uOTk1YTgxYjQ4YTk4OTM2Y2RiZDBhYmJhOGQ2NTk0NWQ1Njkw YzNiOSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3N0cmVh bWVyL21zZS9XZWJLaXRNZWRpYVNvdXJjZUdTdHJlYW1lci5jcHAKKysrIGIvU291cmNlL1dlYkNv cmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3N0cmVhbWVyL21zZS9XZWJLaXRNZWRpYVNvdXJjZUdTdHJl YW1lci5jcHAKQEAgLTUxMyw2ICs1MTMsMTUgQEAgdm9pZCB3ZWJLaXRNZWRpYVNyY0ZyZWVTdHJl YW0oV2ViS2l0TWVkaWFTcmMqIHNvdXJjZSwgU3RyZWFtKiBzdHJlYW0pCiAgICAgICAgIC8vIERv bid0IHRyaWdnZXIgY2FsbGJhY2tzIGZyb20gdGhpcyBhcHBzcmMgdG8gYXZvaWQgdXNpbmcgdGhl IHN0cmVhbSBhbnltb3JlLgogICAgICAgICBnc3RfYXBwX3NyY19zZXRfY2FsbGJhY2tzKEdTVF9B UFBfU1JDKHN0cmVhbS0+YXBwc3JjKSwgJmRpc2FibGVkQXBwc3JjQ2FsbGJhY2tzLCBudWxscHRy LCBudWxscHRyKTsKICAgICAgICAgZ3N0X2FwcF9zcmNfZW5kX29mX3N0cmVhbShHU1RfQVBQX1NS QyhzdHJlYW0tPmFwcHNyYykpOworICAgICAgICBnc3RfZWxlbWVudF9zZXRfc3RhdGUoc3RyZWFt LT5hcHBzcmMsIEdTVF9TVEFURV9OVUxMKTsKKyAgICAgICAgZ3N0X2Jpbl9yZW1vdmUoR1NUX0JJ Tihzb3VyY2UpLCBzdHJlYW0tPmFwcHNyYyk7CisgICAgICAgIHN0cmVhbS0+YXBwc3JjID0gbnVs bHB0cjsKKyAgICB9CisKKyAgICBpZiAoc3RyZWFtLT5wYXJzZXIpIHsKKyAgICAgICAgZ3N0X2Vs ZW1lbnRfc2V0X3N0YXRlKHN0cmVhbS0+cGFyc2VyLCBHU1RfU1RBVEVfTlVMTCk7CisgICAgICAg IGdzdF9iaW5fcmVtb3ZlKEdTVF9CSU4oc291cmNlKSwgc3RyZWFtLT5wYXJzZXIpOworICAgICAg ICBzdHJlYW0tPnBhcnNlciA9IG51bGxwdHI7CiAgICAgfQogCiAgICAgaWYgKHN0cmVhbS0+dHlw ZSAhPSBXZWJDb3JlOjpJbnZhbGlkKSB7CkBAIC01MzEsMTIgKzU0MCwxNSBAQCB2b2lkIHdlYktp dE1lZGlhU3JjRnJlZVN0cmVhbShXZWJLaXRNZWRpYVNyYyogc291cmNlLCBTdHJlYW0qIHN0cmVh bSkKICAgICAgICAgaW50IHNpZ25hbCA9IC0xOwogICAgICAgICBzd2l0Y2ggKHN0cmVhbS0+dHlw ZSkgewogICAgICAgICBjYXNlIFdlYkNvcmU6OkF1ZGlvOgorICAgICAgICAgICAgc291cmNlLT5w cml2LT5udW1iZXJPZkF1ZGlvU3RyZWFtcy0tOwogICAgICAgICAgICAgc2lnbmFsID0gU0lHTkFM X0FVRElPX0NIQU5HRUQ7CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBXZWJDb3Jl OjpWaWRlbzoKKyAgICAgICAgICAgIHNvdXJjZS0+cHJpdi0+bnVtYmVyT2ZWaWRlb1N0cmVhbXMt LTsKICAgICAgICAgICAgIHNpZ25hbCA9IFNJR05BTF9WSURFT19DSEFOR0VEOwogICAgICAgICAg ICAgYnJlYWs7CiAgICAgICAgIGNhc2UgV2ViQ29yZTo6VGV4dDoKKyAgICAgICAgICAgIHNvdXJj ZS0+cHJpdi0+bnVtYmVyT2ZUZXh0U3RyZWFtcy0tOwogICAgICAgICAgICAgc2lnbmFsID0gU0lH TkFMX1RFWFRfQ0hBTkdFRDsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0Ogo= 339534 2018-05-04 03:17:45 -0700 2018-05-04 06:26:18 -0700 Patch bug-185242-20180504121744.patch text/plain 2794 bandou.yacine U3VidmVyc2lvbiBSZXZpc2lvbjogMjMxMDQ0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggZTE4MmIwYThjYjhkN2E4 NmVkNWY1OWE4MTlmNDVmYzU1ZTEwZmQ3ZS4uNzcxYmE0NmM1MmZiZjYzNTM0N2VjMTFhMzgzYjIw NTE0M2M0MTU4MyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE5IEBACisyMDE4LTA1LTAzICBZYWNp bmUgQmFuZG91ICA8eWFjaW5lLmJhbmRvdV9leHRAc29mdGF0aG9tZS5jb20+CisKKyAgICAgICAg W01TRV1bR1N0cmVhbWVyXSBEZWxldGUgcHJvcGVybHkgdGhlIHN0cmVhbSBmcm9tIHRoZSBXZWJL aXRNZWRpYVNvdXJjZQorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j Z2k/aWQ9MTg1MjQyCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg ICAgICAgV2hlbiB0aGUgc291cmNlQnVmZmVyIGlzIHJlbW92ZWQgZnJvbSBtZWRpYXNvdXJjZSwg dGhlIGFwcHJvcHJpYXRlIHN0cmVhbSBpcyBub3QKKyAgICAgICAgcHJvcGVybHkgZGVsZXRlZCBm cm9tIFdlYktpdE1lZGlhU291cmNlLCBiZWNhdXNlIHRoZSBhcHBzcmMgYW5kIHBhcnNlciBlbGVt ZW50cworICAgICAgICBvZiB0aGUgc3RyZWFtIGFyZSBub3QgcmVtb3ZlZCBmcm9tIHRoZSBXZWJL aXRNZWRpYVNvdXJjZSBiaW4uCisKKyAgICAgICAgVGhpcyBwYXRjaCBhdm9pZHMgdGhlIHJlZ3Jl c3Npb24gb2YgcjIzMTA4OSwgc2VlIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0xODUwNzEKKworICAgICAgICAqIHBsYXRmb3JtL2dyYXBoaWNzL2dzdHJlYW1lci9tc2Uv V2ViS2l0TWVkaWFTb3VyY2VHU3RyZWFtZXIuY3BwOgorICAgICAgICAod2ViS2l0TWVkaWFTcmNG cmVlU3RyZWFtKToKKwogMjAxOC0wMS0yNCAgWWFjaW5lIEJhbmRvdSAgPHlhY2luZS5iYW5kb3Vf ZXh0QHNvZnRhdGhvbWUuY29tPgogCiAgICAgICAgIFtFTUVdW0dTdHJlYW1lcl0gTW92ZSB0aGUg ZGVjcnlwdG9yIGZyb20gQXBwZW5kUGlwZWxpbmUgdG8gUGxheWJhY2tQaXBlbGluZS4KZGlmZiAt LWdpdCBhL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2dzdHJlYW1lci9tc2UvV2Vi S2l0TWVkaWFTb3VyY2VHU3RyZWFtZXIuY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3Jh cGhpY3MvZ3N0cmVhbWVyL21zZS9XZWJLaXRNZWRpYVNvdXJjZUdTdHJlYW1lci5jcHAKaW5kZXgg ZDMyZmJhM2VjZGUwZWIxOWM3NmFjZDlmZWQ1ZTVjZGQ0ZmRkOTI2YS4uYmIxNGYyYmNlOGNkZWRm NmJlODY3MjZkMjMyMDlhY2UwYjk5Y2YwNSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxh dGZvcm0vZ3JhcGhpY3MvZ3N0cmVhbWVyL21zZS9XZWJLaXRNZWRpYVNvdXJjZUdTdHJlYW1lci5j cHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3N0cmVhbWVyL21zZS9X ZWJLaXRNZWRpYVNvdXJjZUdTdHJlYW1lci5jcHAKQEAgLTUxMyw4ICs1MTMsMzMgQEAgdm9pZCB3 ZWJLaXRNZWRpYVNyY0ZyZWVTdHJlYW0oV2ViS2l0TWVkaWFTcmMqIHNvdXJjZSwgU3RyZWFtKiBz dHJlYW0pCiAgICAgICAgIC8vIERvbid0IHRyaWdnZXIgY2FsbGJhY2tzIGZyb20gdGhpcyBhcHBz cmMgdG8gYXZvaWQgdXNpbmcgdGhlIHN0cmVhbSBhbnltb3JlLgogICAgICAgICBnc3RfYXBwX3Ny Y19zZXRfY2FsbGJhY2tzKEdTVF9BUFBfU1JDKHN0cmVhbS0+YXBwc3JjKSwgJmRpc2FibGVkQXBw c3JjQ2FsbGJhY2tzLCBudWxscHRyLCBudWxscHRyKTsKICAgICAgICAgZ3N0X2FwcF9zcmNfZW5k X29mX3N0cmVhbShHU1RfQVBQX1NSQyhzdHJlYW0tPmFwcHNyYykpOworICAgICAgICBnc3RfZWxl bWVudF9zZXRfc3RhdGUoc3RyZWFtLT5hcHBzcmMsIEdTVF9TVEFURV9OVUxMKTsKKyAgICAgICAg Z3N0X2Jpbl9yZW1vdmUoR1NUX0JJTihzb3VyY2UpLCBzdHJlYW0tPmFwcHNyYyk7CisgICAgICAg IHN0cmVhbS0+YXBwc3JjID0gbnVsbHB0cjsKICAgICB9CiAKKyAgICBpZiAoc3RyZWFtLT5wYXJz ZXIpIHsKKyAgICAgICAgZ3N0X2VsZW1lbnRfc2V0X3N0YXRlKHN0cmVhbS0+cGFyc2VyLCBHU1Rf U1RBVEVfTlVMTCk7CisgICAgICAgIGdzdF9iaW5fcmVtb3ZlKEdTVF9CSU4oc291cmNlKSwgc3Ry ZWFtLT5wYXJzZXIpOworICAgICAgICBzdHJlYW0tPnBhcnNlciA9IG51bGxwdHI7CisgICAgfQor CisgICAgR1NUX09CSkVDVF9MT0NLKHNvdXJjZSk7CisgICAgc3dpdGNoIChzdHJlYW0tPnR5cGUp IHsKKyAgICBjYXNlIFdlYkNvcmU6OkF1ZGlvOgorICAgICAgICBzb3VyY2UtPnByaXYtPm51bWJl ck9mQXVkaW9TdHJlYW1zLS07CisgICAgICAgIGJyZWFrOworICAgIGNhc2UgV2ViQ29yZTo6Vmlk ZW86CisgICAgICAgIHNvdXJjZS0+cHJpdi0+bnVtYmVyT2ZWaWRlb1N0cmVhbXMtLTsKKyAgICAg ICAgYnJlYWs7CisgICAgY2FzZSBXZWJDb3JlOjpUZXh0OgorICAgICAgICBzb3VyY2UtPnByaXYt Pm51bWJlck9mVGV4dFN0cmVhbXMtLTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAg ICAgICAgYnJlYWs7CisgICAgfQorICAgIEdTVF9PQkpFQ1RfVU5MT0NLKHNvdXJjZSk7CisKICAg ICBpZiAoc3RyZWFtLT50eXBlICE9IFdlYkNvcmU6OkludmFsaWQpIHsKICAgICAgICAgR1NUX0RF QlVHKCJGcmVlaW5nIHRyYWNrLXJlbGF0ZWQgaW5mbyBvbiBzdHJlYW0gJXAiLCBzdHJlYW0pOwog Cg==