66181 2011-08-12 19:22:27 -0700 HTMLPlugInElement persists until page teardown if the plugin requests the script object for it 2011-09-08 20:20:10 -0700 1 1 1 Unclassified WebKit Plug-ins 528+ (Nightly build) PC All RESOLVED FIXED P2 Normal --- 0 wez webkit-unassigned andersca ap webkit.review.bot oldest_to_newest 450789 0 wez 2011-08-12 19:22:27 -0700 Any plugin which requests the script object for the containing element causes the HTMLPlugInElement to generate an NPObject wrapper for itself, which holds a reference to it. It returns this to the plugin, but also retains a reference internally, to return if the plugin requests the script object again. This creates a cyclical reference which prevents the HTMLPlugInElement from being torn down. To reproduce the issue: 1. Arrange to detect HTMLPlugInElement leaks (e.g. and printout to constructor & destructor). 2. Verify that you see HTMLPlugInElement torn-down, by running the TestNetscapePlugIn "getURL" test, for example. 3. Run the TestNetscapePlugIn "testDOMAccess" test, which causes the plugin to request an NPObject for the plugin element, and to then release it when the plugin is torn down. 4. If you're feeling eager, run that test several times from within the same page, creating and tearing down TestNetscapePlugIn elements, so that multiple elements will be leaked. Actual Results: The HTMLPlugInElement should be torn down correctly in (2), but not be in (3) and (4). Expected Results: The HTMLPlugInElement should be torn down when the plug-in is destroyed. Builds & Platforms: This has been observed running WebKit within the Chromium browser, on several platforms. 450961 1 103885 wez 2011-08-14 17:29:50 -0700 Created attachment 103885 Patch 450980 2 103885 ap 2011-08-14 21:34:36 -0700 Comment on attachment 103885 Patch I'm hugely suspicious of this patch. Before changing cross-platform code, please at least confirm that this problem affects other ports. 455589 3 wez 2011-08-23 12:18:53 -0700 I've reproduced the issue with Linux/GtkLauncher. It won't reproduce with Mac/Safari, because the relevant code-path is never invoked. To clarify, the leak occurs only while the calling page is active; when the page is destroyed the objects are still correctly torn down. 455743 4 ap 2011-08-23 15:20:29 -0700 > It won't reproduce with Mac/Safari, because the relevant code-path is never invoked. Are you saying that HTMLPlugInElement::removedFromDocument() is never called on Mac? 455756 5 wez 2011-08-23 15:50:25 -0700 No, HTMLPlugInElement::getNPObject() never seems to be called under Safari. 455815 6 ap 2011-08-23 16:40:38 -0700 OK, so you are changing a function that is called in Safari. Why is it ok, provided that the issue doesn't exist in the Mac port? More generally, what is there difference between ports? 455851 7 wez 2011-08-23 17:18:34 -0700 Sorry for the confusion! The Chromium and Linux/Gtk ports call HTMLPlugInElement::getNPObject() to fetch the plugin element's script object when the plugin requests it. At that point HTMLPlugInElement caches the object, retaining a reference to it. I think Mac/Safari must have its own method of generating a script object for the HTMLPlugInElement, without calling getNPObject(). The plugin element script object is cached presumably so that the plugin will just increase the reference count on a single object if it requests it repeatedly, rather than generating distinct objects. It's therefore reasonable to clear the cached reference when the plugin has been torn down, which should be the case when removedFromDocument() is notified. Clearing the reference in detach() also sounds plausible, but since detach() is notified when an element is hidden, I'm not sure whether that would be correct? The release of the reference in removedFromDocument() is only done if a reference is cached, which will only be the case if getNPObject() was previously called to generate the script object. This also makes it safe on platforms which never call getNPObject(), since on those platforms there will never be a cached reference to release. 455953 8 ap 2011-08-23 21:02:25 -0700 From code inspection, I see that WebKit1 is definitely calling getNPObject(), it's in WebNetscapePluginView.mm. This code path is for in-process plug-ins, so it should be hit when Safari runs in 32-bit WebKit1 mode. Even though this mode is old, I'd be somewhat surprised if we leaked there. 455959 9 wez 2011-08-23 21:33:27 -0700 (In reply to comment #8) > From code inspection, I see that WebKit1 is definitely calling getNPObject(), it's in WebNetscapePluginView.mm. This code path is for in-process plug-ins, so it should be hit when Safari runs in 32-bit WebKit1 mode. That would certainly explain it. > Even though this mode is old, I'd be somewhat surprised if we leaked there. It'll only manifest for plugins that fetch the script object for their element, and the memory will be freed when the page is torn down, so it's a leak you'd only notice if you were adding & removing plugins on a page for quite a while. 455976 10 wez 2011-08-23 22:36:40 -0700 (In reply to comment #9) > (In reply to comment #8) > > From code inspection, I see that WebKit1 is definitely calling getNPObject(), it's in WebNetscapePluginView.mm. This code path is for in-process plug-ins, so it should be hit when Safari runs in 32-bit WebKit1 mode. > > That would certainly explain it. > > > Even though this mode is old, I'd be somewhat surprised if we leaked there. > > It'll only manifest for plugins that fetch the script object for their element, and the memory will be freed when the page is torn down, so it's a leak you'd only notice if you were adding & removing plugins on a page for quite a while. I've tried running Safari 32-bit (via the option under Get Info), but I'm still not seeing getNPObject getting called. 456454 11 wez 2011-08-24 15:13:22 -0700 (In reply to comment #10) > I've tried running Safari 32-bit (via the option under Get Info), but I'm still not seeing getNPObject getting called. I've determined that I was still running 64-bit; I've now got Safari running 32-bit, but of course I can't load my WebKit build nor plugin into it. Is there some flag to provide to build-webkit to get a 32-bit or fat build - I can't find any documentation on how to do that? 456471 12 ap 2011-08-24 15:32:47 -0700 Yes, set-webkit-configuration --32-bit. You will also want to create a WebKit1 window: 1. In Terminal: defaults write com.apple.Safari IncludeInternalDebugMenu 1 2. Restart Safari. 3. Cmd+Option+N (there will be [SP] in window title, standing for "single process"). 456478 13 wez 2011-08-24 15:38:50 -0700 (In reply to comment #12) > Yes, set-webkit-configuration --32-bit. > > You will also want to create a WebKit1 window: > 1. In Terminal: defaults write com.apple.Safari IncludeInternalDebugMenu 1 > 2. Restart Safari. > 3. Cmd+Option+N (there will be [SP] in window title, standing for "single process"). Thanks - will give that a shot! 456572 14 wez 2011-08-24 18:00:36 -0700 (In reply to comment #13) > (In reply to comment #12) > > Yes, set-webkit-configuration --32-bit. > > > > You will also want to create a WebKit1 window: > > 1. In Terminal: defaults write com.apple.Safari IncludeInternalDebugMenu 1 > > 2. Restart Safari. > > 3. Cmd+Option+N (there will be [SP] in window title, standing for "single process"). > > Thanks - will give that a shot! I've got 32-bit Safari running, and a Single-Process window opening, but it segfaults running the TestNetscapePlugIn test, in different ways depending on whether I run it with the system WebKit framework or my debug build. 457075 15 wez 2011-08-25 12:49:43 -0700 (In reply to comment #14) > I've got 32-bit Safari running, and a Single-Process window opening, but it segfaults running the TestNetscapePlugIn test, in different ways depending on whether I run it with the system WebKit framework or my debug build. Since the test crashes Safari 32-bit Single-Process, I've instead verified that: 1. Running single-process, the plugin does cause HTMLPlugInElement::getNPObject() to be invoked, before Safari crashes. 2. Running multi-process, with HTMLPlugInElement modified to call getNPObject itself in getInstance(), the HTMLPlugInElements are not released until the page is closed. 3. Running multi-process, with the modification in (2), and my patch applied, the elements are torn down as they are removed from the document, as you'd expect. These tests were run with removedFromDocument() modified to invoke gcController().garbageCollectNow(), so as to force timely collection of the element reference. 457684 16 ap 2011-08-26 11:42:53 -0700 Thank you! I guess cross-platform code is the right place for the fix then. Are plug-ins completely torn down when an element is removed from document (and then re-created from scratch if the element is put back)? + Release the reference held by HTMLPlugInElement to the wrapping NPObject it may have created for itself, when the element is removed from the document. This breaks a cyclical reference that would otherwise cause the element to be leaked. Calling this a leak is misleading given that the memory is reclaimed when document is closed. CC'ing Anders, who would likely be the best reviewer for this patch anyway. 457759 17 wez 2011-08-26 13:53:00 -0700 (In reply to comment #16) > Thank you! I guess cross-platform code is the right place for the fix then. > > Are plug-ins completely torn down when an element is removed from document (and then re-created from scratch if the element is put back)? My understanding is that plugin lifetimes are tied to the relevant render widgets; if the element is removed or hidden then the plugin will be destroyed. If that is correct then the script object could be cleared in detach() instead, but I chose to be conservative since I couldn't find any documentation of the intended behaviour. Things behave as described above under Chromium, but I've not checked other browsers. > + Release the reference held by HTMLPlugInElement to the wrapping NPObject it may have created for itself, when the element is removed from the document. This breaks a cyclical reference that would otherwise cause the element to be leaked. > > Calling this a leak is misleading given that the memory is reclaimed when document is closed. Yes, although from the point of view of a long-lived document, the two are indistinguishable. I'll try to come up with more precise wording, though. > CC'ing Anders, who would likely be the best reviewer for this patch anyway. Thanks! 457774 18 105407 wez 2011-08-26 14:17:33 -0700 Created attachment 105407 Patch 459378 19 wez 2011-08-30 18:07:55 -0700 (In reply to comment #18) > Created an attachment (id=105407) [details] > Patch Any progress on this? 464350 20 wez 2011-09-08 14:12:14 -0700 (In reply to comment #19) > (In reply to comment #18) > > Created an attachment (id=105407) [details] [details] > > Patch > > Any progress on this? Ping! :) 464364 21 105407 andersca 2011-09-08 14:21:39 -0700 Comment on attachment 105407 Patch Looks fine, r+. Sorry about the delay! 464607 22 105407 webkit.review.bot 2011-09-08 20:20:05 -0700 Comment on attachment 105407 Patch Clearing flags on attachment: 105407 Committed r94831: <http://trac.webkit.org/changeset/94831> 464608 23 webkit.review.bot 2011-09-08 20:20:10 -0700 All reviewed patches have been landed. Closing bug. 103885 2011-08-14 17:29:50 -0700 2011-08-26 14:17:29 -0700 Patch bug-66181-20110814172949.patch text/plain 2315 wez U3VidmVyc2lvbiBSZXZpc2lvbjogOTI5NTkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAxNTkzMzEzNjllZGFkNmM1 ZDk2OGM3MWMzYWRlNGJlNzg2NGQwOWIyLi5jNDllZjJhMTQzZDZjZmMyNTY1NWNiODg0OTAxMDdh YjcyNzU5YmRjIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTcgQEAKKzIwMTEtMDgtMTMgIEphbWVz IFdlYXRoZXJhbGwgIDx3ZXpAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJlbGVhc2UgdGhlIHJl ZmVyZW5jZSBoZWxkIGJ5IEhUTUxQbHVnSW5FbGVtZW50IHRvIHRoZSB3cmFwcGluZyBOUE9iamVj dCBpdCBtYXkgaGF2ZSBjcmVhdGVkIGZvciBpdHNlbGYsIHdoZW4gdGhlIGVsZW1lbnQgaXMgcmVt b3ZlZCBmcm9tIHRoZSBkb2N1bWVudC4gIFRoaXMgYnJlYWtzIGEgY3ljbGljYWwgcmVmZXJlbmNl IHRoYXQgd291bGQgb3RoZXJ3aXNlIGNhdXNlIHRoZSBlbGVtZW50IHRvIGJlIGxlYWtlZC4KKwor ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NjYxODEKKwor ICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBObyBuZXcgdGVz dHMgLSBubyBmdW5jdGlvbmFsIGNoYW5nZS4KKworICAgICAgICAqIGh0bWwvSFRNTFBsdWdJbkVs ZW1lbnQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6SFRNTFBsdWdJbkVsZW1lbnQ6OnJlbW92ZWRG cm9tRG9jdW1lbnQpOgorICAgICAgICAqIGh0bWwvSFRNTFBsdWdJbkVsZW1lbnQuaDoKKwogMjAx MS0wOC0xMiAgUGF2ZWwgRmVsZG1hbiAgPHBmZWxkbWFuQGdvb2dsZS5jb20+CiAKICAgICAgICAg V2ViIEluc3BlY3RvcjogbWFrZSBmb2xkZXJzIG9wdGlvbmFsIGluIHRoZSBTY3JpcHRzJyBwYW5l bCBmaWxlIHNlbGVjdG9yLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvaHRtbC9IVE1MUGx1 Z0luRWxlbWVudC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmNw cAppbmRleCBlYTkwY2ZlOTU2ZTU3YzNmOTQ1NjdiMWZlZTE5NDJiZWM1MzljNzcwLi5jOTA1NDE3 NjFhMjgzNTZmNDVkZDQ2ODE5ODYwNTE1MzE1M2EyOGEyIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2Vi Q29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9odG1s L0hUTUxQbHVnSW5FbGVtZW50LmNwcApAQCAtODEsNiArODEsMTggQEAgdm9pZCBIVE1MUGx1Z0lu RWxlbWVudDo6ZGV0YWNoKCkKICAgICBIVE1MRnJhbWVPd25lckVsZW1lbnQ6OmRldGFjaCgpOwog fQogCit2b2lkIEhUTUxQbHVnSW5FbGVtZW50OjpyZW1vdmVkRnJvbURvY3VtZW50KCkKK3sKKyNp ZiBFTkFCTEUoTkVUU0NBUEVfUExVR0lOX0FQSSkKKyAgICBpZiAobV9OUE9iamVjdCkgeworICAg ICAgICBfTlBOX1JlbGVhc2VPYmplY3QobV9OUE9iamVjdCk7CisgICAgICAgIG1fTlBPYmplY3Qg PSAwOworICAgIH0KKyNlbmRpZgorCisgICAgSFRNTEZyYW1lT3duZXJFbGVtZW50OjpyZW1vdmVk RnJvbURvY3VtZW50KCk7Cit9CisKIFBhc3NTY3JpcHRJbnN0YW5jZSBIVE1MUGx1Z0luRWxlbWVu dDo6Z2V0SW5zdGFuY2UoKQogewogICAgIEZyYW1lKiBmcmFtZSA9IGRvY3VtZW50KCktPmZyYW1l KCk7CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50Lmgg Yi9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmgKaW5kZXggZmQ5OWNhYWY3 ZTNkYTA2OGRkNDZlNDVhYTEzMzk4N2M1MDcxMGMwZi4uMmUzM2M2NjcyNTkxOGU2YmRhMTMzMzc2 ZDYwMzA1ZWE1YjI4NjY0MiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvaHRtbC9IVE1MUGx1 Z0luRWxlbWVudC5oCisrKyBiL1NvdXJjZS9XZWJDb3JlL2h0bWwvSFRNTFBsdWdJbkVsZW1lbnQu aApAQCAtNTcsNyArNTcsNyBAQCBwcm90ZWN0ZWQ6CiAgICAgSFRNTFBsdWdJbkVsZW1lbnQoY29u c3QgUXVhbGlmaWVkTmFtZSYgdGFnTmFtZSwgRG9jdW1lbnQqKTsKIAogICAgIHZpcnR1YWwgdm9p ZCBkZXRhY2goKTsKLQorICAgIHZpcnR1YWwgdm9pZCByZW1vdmVkRnJvbURvY3VtZW50KCk7CiAg ICAgdmlydHVhbCBib29sIG1hcFRvRW50cnkoY29uc3QgUXVhbGlmaWVkTmFtZSYgYXR0ck5hbWUs IE1hcHBlZEF0dHJpYnV0ZUVudHJ5JiByZXN1bHQpIGNvbnN0OwogICAgIHZpcnR1YWwgdm9pZCBw YXJzZU1hcHBlZEF0dHJpYnV0ZShBdHRyaWJ1dGUqKTsKIAo= 105407 2011-08-26 14:17:33 -0700 2011-09-08 20:20:05 -0700 Patch bug-66181-20110826141732.patch text/plain 2270 wez U3VidmVyc2lvbiBSZXZpc2lvbjogOTM3ODEKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAxMjQ4ZTA5MWE0MzQwMmU0 NjBmMjEyZTg5YzlhMmUxNzk5MzgwNTY1Li5jMmVhNmJlNDgyZmViZmIxNGYzMTNjOThiNzMwZjEx MTdkZTg5ZGMyIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTEtMDgtMjYgIEphbWVz IFdlYXRoZXJhbGwgIDx3ZXpAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJlbGVhc2UgdGhlIHJl ZmVyZW5jZSB0byB0aGUgSFRNTFBsdWdJbkVsZW1lbnQncyBzY3JpcHQgb2JqZWN0LCB3aGVuIHRo ZSBlbGVtZW50IGlzIHJlbW92ZWQgZnJvbSB0aGUgZG9jdW1lbnQuICBUaGlzIGJyZWFrcyBhIGN5 Y2xpY2FsIHJlZmVyZW5jZSB0aGF0IHdvdWxkIG90aGVyd2lzZSBjYXVzZSB0aGUgZWxlbWVudCB0 byBiZSByZXRhaW5lZCB1bnRpbCB0aGUgZG9jdW1lbnQgaXMgdG9ybiBkb3duLgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NjYxODEKKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBObyBuZXcgdGVzdHMgLSBubyBm dW5jdGlvbmFsIGNoYW5nZS4KKworICAgICAgICAqIGh0bWwvSFRNTFBsdWdJbkVsZW1lbnQuY3Bw OgorICAgICAgICAoV2ViQ29yZTo6SFRNTFBsdWdJbkVsZW1lbnQ6OnJlbW92ZWRGcm9tRG9jdW1l bnQpOgorICAgICAgICAqIGh0bWwvSFRNTFBsdWdJbkVsZW1lbnQuaDoKKwogMjAxMS0wOC0yNSAg U2hlcmlmZiBCb3QgIDx3ZWJraXQucmV2aWV3LmJvdEBnbWFpbC5jb20+CiAKICAgICAgICAgVW5y ZXZpZXdlZCwgcm9sbGluZyBvdXQgcjkzNzcxLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUv aHRtbC9IVE1MUGx1Z0luRWxlbWVudC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVn SW5FbGVtZW50LmNwcAppbmRleCBlYTkwY2ZlOTU2ZTU3YzNmOTQ1NjdiMWZlZTE5NDJiZWM1Mzlj NzcwLi5jOTA1NDE3NjFhMjgzNTZmNDVkZDQ2ODE5ODYwNTE1MzE1M2EyOGEyIDEwMDY0NAotLS0g YS9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmNwcAorKysgYi9Tb3VyY2Uv V2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmNwcApAQCAtODEsNiArODEsMTggQEAgdm9p ZCBIVE1MUGx1Z0luRWxlbWVudDo6ZGV0YWNoKCkKICAgICBIVE1MRnJhbWVPd25lckVsZW1lbnQ6 OmRldGFjaCgpOwogfQogCit2b2lkIEhUTUxQbHVnSW5FbGVtZW50OjpyZW1vdmVkRnJvbURvY3Vt ZW50KCkKK3sKKyNpZiBFTkFCTEUoTkVUU0NBUEVfUExVR0lOX0FQSSkKKyAgICBpZiAobV9OUE9i amVjdCkgeworICAgICAgICBfTlBOX1JlbGVhc2VPYmplY3QobV9OUE9iamVjdCk7CisgICAgICAg IG1fTlBPYmplY3QgPSAwOworICAgIH0KKyNlbmRpZgorCisgICAgSFRNTEZyYW1lT3duZXJFbGVt ZW50OjpyZW1vdmVkRnJvbURvY3VtZW50KCk7Cit9CisKIFBhc3NTY3JpcHRJbnN0YW5jZSBIVE1M UGx1Z0luRWxlbWVudDo6Z2V0SW5zdGFuY2UoKQogewogICAgIEZyYW1lKiBmcmFtZSA9IGRvY3Vt ZW50KCktPmZyYW1lKCk7CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVn SW5FbGVtZW50LmggYi9Tb3VyY2UvV2ViQ29yZS9odG1sL0hUTUxQbHVnSW5FbGVtZW50LmgKaW5k ZXggZmQ5OWNhYWY3ZTNkYTA2OGRkNDZlNDVhYTEzMzk4N2M1MDcxMGMwZi4uMmUzM2M2NjcyNTkx OGU2YmRhMTMzMzc2ZDYwMzA1ZWE1YjI4NjY0MiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUv aHRtbC9IVE1MUGx1Z0luRWxlbWVudC5oCisrKyBiL1NvdXJjZS9XZWJDb3JlL2h0bWwvSFRNTFBs dWdJbkVsZW1lbnQuaApAQCAtNTcsNyArNTcsNyBAQCBwcm90ZWN0ZWQ6CiAgICAgSFRNTFBsdWdJ bkVsZW1lbnQoY29uc3QgUXVhbGlmaWVkTmFtZSYgdGFnTmFtZSwgRG9jdW1lbnQqKTsKIAogICAg IHZpcnR1YWwgdm9pZCBkZXRhY2goKTsKLQorICAgIHZpcnR1YWwgdm9pZCByZW1vdmVkRnJvbURv Y3VtZW50KCk7CiAgICAgdmlydHVhbCBib29sIG1hcFRvRW50cnkoY29uc3QgUXVhbGlmaWVkTmFt ZSYgYXR0ck5hbWUsIE1hcHBlZEF0dHJpYnV0ZUVudHJ5JiByZXN1bHQpIGNvbnN0OwogICAgIHZp cnR1YWwgdm9pZCBwYXJzZU1hcHBlZEF0dHJpYnV0ZShBdHRyaWJ1dGUqKTsKIAo=