92198 2012-07-24 20:10:06 -0700 Web Inspector: debugging long-running scripts with conditional breakpoints consumes huge amounts of memory 2026-01-12 09:04:01 -0800 1 1 1 Unclassified WebKit Web Inspector 528+ (Nightly build) All All UNCONFIRMED InRadar P2 Normal --- 0 felixcca webkit-unassigned apavlov bweinstein charles.wei ggaren graouts inspector-bugzilla-changes keishi loislo PeterHWang pfeldman pmuellr rik webkit-bug-importer yurys oldest_to_newest 677551 0 felixcca 2012-07-24 20:10:06 -0700 When uninterrupted, long-running scripts execute under the Javascript debugger, and those scripts have conditional breakpoints, WebProcess will consume huge amounts of memory for seemingly little reason. On the test case attached, with the conditional breakpoints, memory consumption continually grows to the point where there's no more free memory available. With the conditional breakpoints off, memory usage remains about stable. STEPS TO REPRODUCE 1. Launch the attached web page 2. Open the Web inspector, start the debugger 3. Add 4 conditional breakpoints, one per line inside the `for` loop of the `foo` function, and give them an unlikely condition (`i == -1` for instance) 4. With your favorite diagnostics tool, watch WebProcess eat up all the memory it can 677552 1 154228 felixcca 2012-07-24 20:10:35 -0700 Created attachment 154228 The test case 790364 2 PeterHWang 2012-12-13 00:28:10 -0800 This problem is more obvious in memory-limited environment (e.g. mobile). The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition. There is an interesting test. if you put a normal breakpoint after the breakpoint with failed condition, the GC is working well. Since for a success breakpoint JSC run an EventLoop. 790373 3 179222 PeterHWang 2012-12-13 00:37:24 -0800 Created attachment 179222 Patch 790379 4 179222 yurys 2012-12-13 00:49:50 -0800 Comment on attachment 179222 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=179222&action=review > Source/WebCore/ChangeLog:11 > + No new test case. Can you add a layout test for this? Since the problem is on the back-end you can add a protocol test for it(LayoutTests/inspector-protocol) 790389 5 PeterHWang 2012-12-13 01:04:03 -0800 (In reply to comment #4) > (From update of attachment 179222 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=179222&action=review > > > Source/WebCore/ChangeLog:11 > > + No new test case. > > Can you add a layout test for this? Since the problem is on the back-end you can add a protocol test for it(LayoutTests/inspector-protocol) ok. Let me a try. 790399 6 yurys 2012-12-13 01:19:46 -0800 (In reply to comment #2) > This problem is more obvious in memory-limited environment (e.g. mobile). > > The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition. > It sounds weird that the issue is specific to breakpoint conditions. How does it work in case of eval producing a lot of garbage in a tight loop in user code? > There is an interesting test. if you put a normal breakpoint after the breakpoint with failed condition, the GC is working well. Since for a success breakpoint JSC run an EventLoop. 791230 7 PeterHWang 2012-12-13 18:55:24 -0800 (In reply to comment #6) > (In reply to comment #2) > > This problem is more obvious in memory-limited environment (e.g. mobile). > > > > The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition. > > > It sounds weird that the issue is specific to breakpoint conditions. How does it work in case of eval producing a lot of garbage in a tight loop in user code? > Sorry to reply so late, since I spent some time to investigate the related code of JSC. For the code like this: for (var i=0;i<0xfffff;i++) { ... eval("..."); ... } The "EvalExecutable" is allocated just once and saved as an argument of current callFrame (Interpreter.cpp:149). But to evaluate the condition of breakpoint, the DebuggerCallFrame::evaluate is invoked, the "EvalExecutable" is allocated every time. Maybe, because it's difficult to bind the breakpoint-condition's string with a certain callFrame. 791444 8 yurys 2012-12-14 01:02:09 -0800 (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #2) > > > This problem is more obvious in memory-limited environment (e.g. mobile). > > > > > > The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition. > > > > > It sounds weird that the issue is specific to breakpoint conditions. How does it work in case of eval producing a lot of garbage in a tight loop in user code? > > > Sorry to reply so late, since I spent some time to investigate the related code of JSC. For the code like this: > for (var i=0;i<0xfffff;i++) { > ... > eval("..."); > ... > } > The "EvalExecutable" is allocated just once and saved as an argument of current callFrame (Interpreter.cpp:149). > > But to evaluate the condition of breakpoint, the DebuggerCallFrame::evaluate is invoked, the "EvalExecutable" is allocated every time. Maybe, because it's difficult to bind the breakpoint-condition's string with a certain callFrame. Why JSC cannot run GC automatically during the breakpoint condition evaluation if it needs to free some memory? We need someone who understands JSC garbage collector details to look at this change. 791452 9 PeterHWang 2012-12-14 01:16:49 -0800 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #2) > > > > This problem is more obvious in memory-limited environment (e.g. mobile). > > > > > > > > The root reason is that, for failed condition of breakpoint, JSC doesn't run the EventLoop, so in a dense loop of js code, there is no chance to recycle garbage caused by evaluating the breakpoint's condition. > > > > > > > It sounds weird that the issue is specific to breakpoint conditions. How does it work in case of eval producing a lot of garbage in a tight loop in user code? > > > > > Sorry to reply so late, since I spent some time to investigate the related code of JSC. For the code like this: > > for (var i=0;i<0xfffff;i++) { > > ... > > eval("..."); > > ... > > } > > The "EvalExecutable" is allocated just once and saved as an argument of current callFrame (Interpreter.cpp:149). > > > > But to evaluate the condition of breakpoint, the DebuggerCallFrame::evaluate is invoked, the "EvalExecutable" is allocated every time. Maybe, because it's difficult to bind the breakpoint-condition's string with a certain callFrame. > > Why JSC cannot run GC automatically during the breakpoint condition evaluation if it needs to free some memory? We need someone who understands JSC garbage collector details to look at this change. I'm not expert of it. It depends on the strategy of port, usually JSC does GC with a interval-changeable timer. So need to run EventLoop to handle the timer message. I believe the design of JSC takes repeat "eval()" into account, but the mechanism of debugger works-around it. Welcome JSC's experts to have a look. 1051353 10 burg 2014-11-29 19:18:15 -0800 This still repros on TOT. 1051354 11 webkit-bug-importer 2014-11-29 19:18:31 -0800 <rdar://problem/19096505> 154228 2012-07-24 20:10:35 -0700 2012-07-24 20:10:35 -0700 The test case conditional-breakpoint.html text/html 682 felixcca PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiPgpmdW5jdGlvbiBmb28oKQp7Cgl2YXIgdG90YWwgPSAwOwoJZm9yICh2YXIgaSA9IDA7IGkg PCAweGRlYWRiZWVmOyBpKyspCgl7CgkJdG90YWwgKz0gTWF0aC5jZWlsKGJheihpKSAvIGJhcihp KSk7CgkJdG90YWwrKzsKCQl0b3RhbCAvPSAxLjE7CgkJdG90YWwgPSBNYXRoLmZsb29yKHRvdGFs KTsKCX0KCXJldHVybiB0b3RhbDsKfQoKZnVuY3Rpb24gYmFyKGkpCnsKCXJldHVybiBNYXRoLnNx cnQoaSAlIDEzMzU3KTsKfQoKZnVuY3Rpb24gYmF6KGkpCnsKCXJldHVybiBpICogTWF0aC5sb2co aSkgLyBNYXRoLmxvZygyKTsKfQoKZG9jdW1lbnQuYWRkRXZlbnRMaXN0ZW5lcignRE9NQ29udGVu dExvYWRlZCcsIGZ1bmN0aW9uKCkKewoJZG9jdW1lbnQucXVlcnlTZWxlY3RvcignI2hlcmUnKS5h ZGRFdmVudExpc3RlbmVyKCdjbGljaycsIGZ1bmN0aW9uKCkKCXsKCQlkb2N1bWVudC5xdWVyeVNl bGVjdG9yKCcjYW5zd2VyJykudGV4dENvbnRlbnQgPSBmb28oKTsKCX0pCn0pOwo8L3NjcmlwdD4K PC9oZWFkPgo8Ym9keT4KVGhlIGFuc3dlciBpcyA8YSBpZD0iaGVyZSIgaHJlZj0iIyI+KGNsaWNr IGhlcmUpPC9hPi4uLiA8c3BhbiBpZD0iYW5zd2VyIj48L3NwYW4+CjwvYm9keT4KPC9odG1sPg== 179222 2012-12-13 00:37:24 -0800 2012-12-13 01:21:10 -0800 Patch bug-92198-20121213163442.patch text/plain 4955 PeterHWang U3VidmVyc2lvbiBSZXZpc2lvbjogMTM3MDk5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggZmYyMjMyYzJhYTAyYWU1 N2YzNDBhNzNjYzhkZjI0ZTAzZjZhYWY2MS4uZTQ5YTYxNmU5NzE1MzY3N2VlNzZhOWEzMzI4N2Ix OTRjNTJmOWUyOCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIzIEBACisyMDEyLTEyLTEzICBQZXRl ciBXYW5nICA8cGV0ZXIud2FuZ0B0b3JjaG1vYmlsZS5jb20uY24+CisKKyAgICAgICAgV2ViIElu c3BlY3RvcjogW0pTQ10gZGVidWdnaW5nIGxvbmctcnVubmluZyBzY3JpcHRzIHdpdGggY29uZGl0 aW9uYWwgYnJlYWtwb2ludHMgY29uc3VtZXMgaHVnZSBhbW91bnRzIG9mIG1lbW9yeQorICAgICAg ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9OTIxOTgKKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSdW4gb25lc2hvdCBvZiBF dmVudExvb3AgZm9yIHRoZSBjb25kaXRvbi1mYWlsZWQgYnJlYWtwb2ludCB0byBnaXZlIEpTQyBh IGNoYW5jZSB0byBkbyBHQyBpbgorICAgICAgICB0aGUgY2FzZSBpZiB0aGVyZSBpcyBhIGRlbmNl IGxvb3Agb2YgSlMgY29kZS4KKworICAgICAgICBObyBuZXcgdGVzdCBjYXNlLgorCisgICAgICAg ICogYmluZGluZ3MvanMvU2NyaXB0RGVidWdTZXJ2ZXIuY3BwOgorICAgICAgICAoV2ViQ29yZTo6 U2NyaXB0RGVidWdTZXJ2ZXI6Omhhc0JyZWFrcG9pbnQpOgorICAgICAgICAoV2ViQ29yZSk6Cisg ICAgICAgIChXZWJDb3JlOjpTY3JpcHREZWJ1Z1NlcnZlcjo6ZXZhbENvbmRpdGlvbk9mQnJlYWtw b2ludCk6CisgICAgICAgIChXZWJDb3JlOjpTY3JpcHREZWJ1Z1NlcnZlcjo6cGF1c2VJZk5lZWRl ZCk6CisgICAgICAgICogYmluZGluZ3MvanMvU2NyaXB0RGVidWdTZXJ2ZXIuaDoKKyAgICAgICAg KFNjcmlwdERlYnVnU2VydmVyKToKKwogMjAxMi0xMi0wOSAgSm9hbm1hcmllIERpZ2dzICA8amRp Z2dzQGlnYWxpYS5jb20+CiAKICAgICAgICAgW0dUS10gYWNjZXNzaWJpbGl0eS9wbGFjZWhvbGRl ci5odG1sIGlzIGZhaWxpbmcKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL2pz L1NjcmlwdERlYnVnU2VydmVyLmNwcCBiL1NvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL2pzL1Njcmlw dERlYnVnU2VydmVyLmNwcAppbmRleCA3ZDdjMWZkOWUzMzZhNjczZmEwYTRkNTA2ZjFjN2Q3OWQ3 YWQ0ZmQzLi44MjI2NTY4MDQxMGFmOGYzMmIzZTNkMjQ1ZmVmYjgwM2I0NDhmMDZkIDEwMDY0NAot LS0gYS9Tb3VyY2UvV2ViQ29yZS9iaW5kaW5ncy9qcy9TY3JpcHREZWJ1Z1NlcnZlci5jcHAKKysr IGIvU291cmNlL1dlYkNvcmUvYmluZGluZ3MvanMvU2NyaXB0RGVidWdTZXJ2ZXIuY3BwCkBAIC0z NCw2ICszNCw3IEBACiAjaW5jbHVkZSAiU2NyaXB0RGVidWdTZXJ2ZXIuaCIKIAogI2luY2x1ZGUg IkNvbnRlbnRTZWFyY2hVdGlscy5oIgorI2luY2x1ZGUgIkV2ZW50TG9vcC5oIgogI2luY2x1ZGUg IkZyYW1lLmgiCiAjaW5jbHVkZSAiSlNKYXZhU2NyaXB0Q2FsbEZyYW1lLmgiCiAjaW5jbHVkZSAi SmF2YVNjcmlwdENhbGxGcmFtZS5oIgpAQCAtMTI3LDcgKzEyOCw3IEBAIHZvaWQgU2NyaXB0RGVi dWdTZXJ2ZXI6OnJlbW92ZUJyZWFrcG9pbnQoY29uc3QgU3RyaW5nJiBicmVha3BvaW50SWQpCiAg ICAgfQogfQogCi1ib29sIFNjcmlwdERlYnVnU2VydmVyOjpoYXNCcmVha3BvaW50KGludHB0cl90 IHNvdXJjZUlELCBjb25zdCBUZXh0UG9zaXRpb24mIHBvc2l0aW9uKSBjb25zdAorYm9vbCBTY3Jp cHREZWJ1Z1NlcnZlcjo6aGFzQnJlYWtwb2ludChpbnRwdHJfdCBzb3VyY2VJRCwgY29uc3QgVGV4 dFBvc2l0aW9uJiBwb3NpdGlvbiwgU3RyaW5nJiBjb25kaXRpb24pCiB7CiAgICAgaWYgKCFtX2Jy ZWFrcG9pbnRzQWN0aXZhdGVkKQogICAgICAgICByZXR1cm4gZmFsc2U7CkBAIC0xNjIsMTcgKzE2 MywyOSBAQCBib29sIFNjcmlwdERlYnVnU2VydmVyOjpoYXNCcmVha3BvaW50KGludHB0cl90IHNv dXJjZUlELCBjb25zdCBUZXh0UG9zaXRpb24mIHBvcwogICAgIGlmICghaGl0KQogICAgICAgICBy ZXR1cm4gZmFsc2U7CiAKKyAgICBjb25kaXRpb24gPSBicmVha3NWZWN0b3IuYXQoaSkuY29uZGl0 aW9uOworICAgIHJldHVybiB0cnVlOworfQorCitib29sIFNjcmlwdERlYnVnU2VydmVyOjpldmFs Q29uZGl0aW9uT2ZCcmVha3BvaW50KEpTR2xvYmFsT2JqZWN0KiBkeW5hbWljR2xvYmFsT2JqZWN0 LCBjb25zdCBTdHJpbmcmIGNvbmRpdGlvbikKK3sKICAgICAvLyBBbiBlbXB0eSBjb25kaXRpb24g Y291bnRzIGFzIG5vIGNvbmRpdGlvbiB3aGljaCBpcyBlcXVpdmFsZW50IHRvICJ0cnVlIi4KLSAg ICBpZiAoYnJlYWtzVmVjdG9yLmF0KGkpLmNvbmRpdGlvbi5pc0VtcHR5KCkpCisgICAgaWYgKGNv bmRpdGlvbi5pc0VtcHR5KCkpCiAgICAgICAgIHJldHVybiB0cnVlOwogCiAgICAgSlNWYWx1ZSBl eGNlcHRpb247Ci0gICAgSlNWYWx1ZSByZXN1bHQgPSBtX2N1cnJlbnRDYWxsRnJhbWUtPmV2YWx1 YXRlKGJyZWFrc1ZlY3Rvci5hdChpKS5jb25kaXRpb24sIGV4Y2VwdGlvbik7Ci0gICAgaWYgKGV4 Y2VwdGlvbikgewotICAgICAgICAvLyBBbiBlcnJvbmVvdXMgY29uZGl0aW9uIGNvdW50cyBhcyAi ZmFsc2UiLgorICAgIEpTVmFsdWUgcmVzdWx0ID0gbV9jdXJyZW50Q2FsbEZyYW1lLT5ldmFsdWF0 ZShjb25kaXRpb24sIGV4Y2VwdGlvbik7CisgICAgLy8gQW4gZXJyb25lb3VzIGNvbmRpdGlvbiBj b3VudHMgYXMgImZhbHNlIi4KKyAgICBpZiAoZXhjZXB0aW9uIHx8ICFyZXN1bHQudG9Cb29sZWFu KG1fY3VycmVudENhbGxGcmFtZS0+ZXhlYygpKSkgeworICAgICAgICAvLyBSdW4gb25lc2hvdCBv ZiBFdmVudExvb3AgdG8gZ2l2ZSBKU0MgYSBjaGFuY2UgdG8gZG8gR0MKKyAgICAgICAgZGlkUGF1 c2UoZHluYW1pY0dsb2JhbE9iamVjdCk7CisgICAgICAgIEV2ZW50TG9vcCBsb29wOworICAgICAg ICBsb29wLmN5Y2xlKCk7CisgICAgICAgIGRpZENvbnRpbnVlKGR5bmFtaWNHbG9iYWxPYmplY3Qp OwogICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAgfQotICAgIHJldHVybiByZXN1bHQudG9Cb29s ZWFuKG1fY3VycmVudENhbGxGcmFtZS0+ZXhlYygpKTsKKworICAgIHJldHVybiB0cnVlOwogfQog CiB2b2lkIFNjcmlwdERlYnVnU2VydmVyOjpjbGVhckJyZWFrcG9pbnRzKCkKQEAgLTQyNCwxMyAr NDM3LDE3IEBAIHZvaWQgU2NyaXB0RGVidWdTZXJ2ZXI6OnBhdXNlSWZOZWVkZWQoSlNHbG9iYWxP YmplY3QqIGR5bmFtaWNHbG9iYWxPYmplY3QpCiAgICAgaWYgKCFnZXRMaXN0ZW5lcnNGb3JHbG9i YWxPYmplY3QoZHluYW1pY0dsb2JhbE9iamVjdCkpCiAgICAgICAgIHJldHVybjsKIAorICAgIFN0 cmluZyBjb25kaXRpb25PZkJyZWFrcG9pbnQoIiIpOwogICAgIGJvb2wgcGF1c2VOb3cgPSBtX3Bh dXNlT25OZXh0U3RhdGVtZW50OwogICAgIHBhdXNlTm93IHw9IChtX3BhdXNlT25DYWxsRnJhbWUg PT0gbV9jdXJyZW50Q2FsbEZyYW1lKTsKLSAgICBwYXVzZU5vdyB8PSBoYXNCcmVha3BvaW50KG1f Y3VycmVudENhbGxGcmFtZS0+c291cmNlSUQoKSwgbV9jdXJyZW50Q2FsbEZyYW1lLT5wb3NpdGlv bigpKTsKKyAgICBwYXVzZU5vdyB8PSBoYXNCcmVha3BvaW50KG1fY3VycmVudENhbGxGcmFtZS0+ c291cmNlSUQoKSwgbV9jdXJyZW50Q2FsbEZyYW1lLT5wb3NpdGlvbigpLCBjb25kaXRpb25PZkJy ZWFrcG9pbnQpOwogICAgIG1fbGFzdEV4ZWN1dGVkTGluZSA9IG1fY3VycmVudENhbGxGcmFtZS0+ cG9zaXRpb24oKS5tX2xpbmUuemVyb0Jhc2VkSW50KCk7CiAgICAgaWYgKCFwYXVzZU5vdykKICAg ICAgICAgcmV0dXJuOwogCisgICAgaWYgKCFldmFsQ29uZGl0aW9uT2ZCcmVha3BvaW50KGR5bmFt aWNHbG9iYWxPYmplY3QsIGNvbmRpdGlvbk9mQnJlYWtwb2ludCkpCisgICAgICAgIHJldHVybjsK KwogICAgIG1fcGF1c2VPbkNhbGxGcmFtZSA9IDA7CiAgICAgbV9wYXVzZU9uTmV4dFN0YXRlbWVu dCA9IGZhbHNlOwogICAgIG1fcGF1c2VkID0gdHJ1ZTsKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJD b3JlL2JpbmRpbmdzL2pzL1NjcmlwdERlYnVnU2VydmVyLmggYi9Tb3VyY2UvV2ViQ29yZS9iaW5k aW5ncy9qcy9TY3JpcHREZWJ1Z1NlcnZlci5oCmluZGV4IDY0YWRjNGFlMmY0NDk3ZDhlNDVmZGM4 ZWNmNThiOTBiYzY2MDlmZGQuLmMxMmM3N2RlNjU5ZmE1ZWY2NzFjYzhlOTg0N2M2YThlMjZiYzI5 ZTIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL2pzL1NjcmlwdERlYnVnU2Vy dmVyLmgKKysrIGIvU291cmNlL1dlYkNvcmUvYmluZGluZ3MvanMvU2NyaXB0RGVidWdTZXJ2ZXIu aApAQCAtMTIzLDcgKzEyMyw5IEBAIHByb3RlY3RlZDoKIAogICAgIHZpcnR1YWwgYm9vbCBpc0Nv bnRlbnRTY3JpcHQoSlNDOjpFeGVjU3RhdGUqKTsKIAotICAgIGJvb2wgaGFzQnJlYWtwb2ludChp bnRwdHJfdCBzb3VyY2VJRCwgY29uc3QgVGV4dFBvc2l0aW9uJikgY29uc3Q7CisgICAgYm9vbCBo YXNCcmVha3BvaW50KGludHB0cl90IHNvdXJjZUlELCBjb25zdCBUZXh0UG9zaXRpb24mLCBTdHJp bmcmKTsKKyAgICBib29sIGV2YWxDb25kaXRpb25PZkJyZWFrcG9pbnQoSlNDOjpKU0dsb2JhbE9i amVjdCosIGNvbnN0IFN0cmluZyYpOworCiAKICAgICB2b2lkIGRpc3BhdGNoRnVuY3Rpb25Ub0xp c3RlbmVycyhKYXZhU2NyaXB0RXhlY3V0aW9uQ2FsbGJhY2ssIEpTQzo6SlNHbG9iYWxPYmplY3Qq KTsKICAgICB2b2lkIGRpc3BhdGNoRnVuY3Rpb25Ub0xpc3RlbmVycyhjb25zdCBMaXN0ZW5lclNl dCYgbGlzdGVuZXJzLCBKYXZhU2NyaXB0RXhlY3V0aW9uQ2FsbGJhY2sgY2FsbGJhY2spOwo=