40598 2010-06-14 16:16:31 -0700 [Qt] QtWebkit Crashes on loading CelticKane Standard tests 2010-10-05 03:02:51 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) S60 Hardware S60 3rd edition RESOLVED FIXED Qt, QtTriaged P2 Normal --- 1 ostap73 webkit-unassigned ademar ap commit-queue ggaren hausmann jukka.jokiniva koshuin laszlo.gombos oliver oldest_to_newest 238125 0 ostap73 2010-06-14 16:16:31 -0700 Crash in JavaScriptCore on S60 running popular Javascript benchmark case. Caused by stack overflow. The related call stack . -------------------------------------------------- 68 JSC::arrayProtoFuncToString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\ArrayPrototype.cpp:180 0x4987601a 67 JSC::call() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\CallData.cpp:36 0x4987c96d 66 JSC::callDefaultValueFunction() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:245 0x4989a110 65 JSC::JSObject::defaultValue() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:266 0x49899f30 64 JSC::JSObject::toPrimitive() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.h:590 0x497f32b7 63 JSC::JSObject::toString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:487 0x4989ad53 62 JSC::JSValue::toString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSString.h:275 0x49802c32 61 JSC::arrayProtoFuncToString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\ArrayPrototype.cpp:181 0x4987602f 60 JSC::call() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\CallData.cpp:36 0x4987c96d 59 JSC::callDefaultValueFunction() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:245 0x4989a110 58 JSC::JSObject::defaultValue() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:266 0x49899f30 57 JSC::JSObject::toPrimitive() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.h:590 0x497f32b7 56 JSC::JSObject::toString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSObject.cpp:487 0x4989ad53 55 JSC::JSValue::toString() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSString.h:275 0x49802c32 54 JSC::JSArray::sort() Y:\qt\src\3rdparty\webkit\JavaScriptCore\runtime\JSArray.cpp:701 0x498920bd ------------------------------------------------------------- arrayProtoFuncToString() function allocates quite big object on stack. 238143 1 58728 ostap73 2010-06-14 16:55:32 -0700 Created attachment 58728 Move big allocation from stack to heap. 238467 2 ap 2010-06-15 10:53:23 -0700 I don't know if the inline capacity was added here based on actual measurements, but this change may negatively affect performance. 238473 3 ostap73 2010-06-15 11:09:34 -0700 (In reply to comment #2) > I don't know if the inline capacity was added here based on actual measurements, but this change may negatively affect performance. We've done some benchmarking (test_page.html): linux Vector on stack, buffer on stack: 43 - 44 ms Vector on heap, buffer on heap: 44 - 45 ms Vector on stack, buffer on heap: 43.5 - 44 ms Windows XP Vector on stack, buffer on stack: 83 - 84 ms Vector on heap, buffer on heap: 94 - 95 ms Vector on stack, buffer on heap: 88 - 89 ms Yes, it affects performance, but it seems the difference is not big. This code could be called recursively and 1k buffer on stack is not right. 238474 4 58798 ostap73 2010-06-15 11:10:45 -0700 Created attachment 58798 Benchmark (test_page.html) 246480 5 oliver 2010-07-04 20:21:40 -0700 (In reply to comment #3) > (In reply to comment #2) > > I don't know if the inline capacity was added here based on actual measurements, but this change may negatively affect performance. > > We've done some benchmarking (test_page.html): > > linux > Vector on stack, buffer on stack: 43 - 44 ms > Vector on heap, buffer on heap: 44 - 45 ms > Vector on stack, buffer on heap: 43.5 - 44 ms > > Windows XP > Vector on stack, buffer on stack: 83 - 84 ms > Vector on heap, buffer on heap: 94 - 95 ms > Vector on stack, buffer on heap: 88 - 89 ms > > Yes, it affects performance, but it seems the difference is not big. > This code could be called recursively and 1k buffer on stack is not right. Can we get sunspider numbers? 247111 6 58728 ggaren 2010-07-06 10:08:38 -0700 Comment on attachment 58728 Move big allocation from stack to heap. Even if this is the right approach (and, without any SunSpider numbers, I'm not convinced that it is), I don't think the inline capacity should go all the way to 0. How about 16? How much stack does S60 have? If S60's stack space is truly pathologically small, maybe the best solution is just to conditionally disable all Vector inline capacity on S60. Should be pretty easy to make that change in wtf/Vector.h. 254787 7 62296 ostap73 2010-07-22 07:45:40 -0700 Created attachment 62296 Symbian only patch 254790 8 ostap73 2010-07-22 07:48:00 -0700 > If S60's stack space is truly pathologically small, maybe the best solution is just to conditionally disable all Vector inline capacity on S60. Should be pretty easy to make that change in wtf/Vector.h. Disabling inline i Vector.h is not right, because vectors could be inlined in structures that are not on stack. 254979 9 ggaren 2010-07-22 14:25:00 -0700 > Disabling inline i Vector.h is not right, because vectors could be inlined in structures that are not on stack. Yes, there would be collateral damage from this change. But if S60's stack is so small, what alternative do we have to ensure that the stack-allocated vectors we use don't cause stack overflow? 255000 10 ostap73 2010-07-22 14:53:33 -0700 (In reply to comment #9) > > Disabling inline i Vector.h is not right, because vectors could be inlined in structures that are not on stack. > > Yes, there would be collateral damage from this change. > > But if S60's stack is so small, what alternative do we have to ensure that the stack-allocated vectors we use don't cause stack overflow? I've checked. There is not very much stack allocations of inlined vectors. And more important, those functions wouldn't be called recursively. The problem here in recursive allocation of 1k object on stack. 260164 11 hausmann 2010-08-04 12:54:49 -0700 What about increasing the stack size of the application, using EPOCSTACKSIZE? 260175 12 ostap73 2010-08-04 13:08:32 -0700 (In reply to comment #11) > What about increasing the stack size of the application, using EPOCSTACKSIZE? How big should it be? I've tried increasing stack size to 512kb and it still was crashing. Should it be set bigger? Is it practical for mobile platform? 273827 13 koshuin 2010-09-03 01:04:21 -0700 (In reply to comment #12) > (In reply to comment #11) > > What about increasing the stack size of the application, using EPOCSTACKSIZE? > > How big should it be? > I've tried increasing stack size to 512kb and it still was crashing. > Should it be set bigger? Is it practical for mobile platform? Qt already sets the stack to maximum of 80kB for main thread (with EPOCSTACKSIZE). This value is hardcoded in kernel and cannot be increased any further. If this is not run in the main thread then you can increase it up to 80kB from the default of 8kB. BTW: I have succesfully ran Celtikane tests with QtWebkit before so this can be considered as regression if that makes any difference. 280006 14 62296 kling 2010-09-16 04:11:42 -0700 Comment on attachment 62296 Symbian only patch Since we cannot increase the stack size beyond 80kB on Symbian, this looks like a reasonable solution to me. 280100 15 62296 ap 2010-09-16 08:17:40 -0700 Comment on attachment 62296 Symbian only patch Please at least add a comment explaining why SYMBIAN is different here. 280289 16 67831 ostap73 2010-09-16 12:47:59 -0700 Created attachment 67831 Added comment about symbian stack 280295 17 67831 kling 2010-09-16 13:08:54 -0700 Comment on attachment 67831 Added comment about symbian stack Good call, AP. 281107 18 62296 eric 2010-09-18 03:19:48 -0700 Comment on attachment 62296 Symbian only patch Cleared Andreas Kling's review+ from obsolete attachment 62296 so that this bug does not appear in http://webkit.org/pending-commit. 288246 19 67831 commit-queue 2010-10-01 07:56:30 -0700 Comment on attachment 67831 Added comment about symbian stack Clearing flags on attachment: 67831 Committed r68890: <http://trac.webkit.org/changeset/68890> 288247 20 commit-queue 2010-10-01 07:56:37 -0700 All reviewed patches have been landed. Closing bug. 289514 21 ademar 2010-10-05 03:02:41 -0700 Revision r68890 cherry-picked into qtwebkit-2.1 with commit 1254672 <http://gitorious.org/webkit/qtwebkit/commit/1254672> 58728 2010-06-14 16:55:32 -0700 2010-07-22 07:45:40 -0700 Move big allocation from stack to heap. js_stack_overflow_01.diff text/plain 1349 ostap73 SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDYxMTU5KQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTAtMDYtMTQgIFZpYXRjaGVz bGF2IE9zdGFwZW5rbyAgPG9zdGFwZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgW1F0XSBTdGFjayBvdmVy ZmxvdyBvbiBzeW1iaWFuIHBsYXRmb3JtLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9NDA1OTgKKyAgICAgICAgCisgICAgICAgIE1vdmUgYmlnIGFsbG9j YXRpb24gaW4gYXJyYXlQcm90b0Z1bmNUb1N0cmluZyBmcm9tIHN0YWNrIHRvIGhlYXAuCisKKyAg ICAgICAgKiBydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcDoKKyAgICAgICAgKEpTQzo6YXJyYXlQ cm90b0Z1bmNUb1N0cmluZyk6CisKIDIwMTAtMDYtMTEgIEVyaWMgU2VpZGVsICA8ZXJpY0B3ZWJr aXQub3JnPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEFkYW0gQmFydGguCkluZGV4OiBKYXZhU2Ny aXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2Ny aXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAkocmV2aXNpb24gNjExMzUpCisrKyBK YXZhU2NyaXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAkod29ya2luZyBjb3B5KQpA QCAtMTY5LDcgKzE2OSw3IEBAIEVuY29kZWRKU1ZhbHVlIEpTQ19IT1NUX0NBTEwgYXJyYXlQcm90 b0YKIAogICAgIHVuc2lnbmVkIGxlbmd0aCA9IHRoaXNPYmotPmdldChleGVjLCBleGVjLT5wcm9w ZXJ0eU5hbWVzKCkubGVuZ3RoKS50b1VJbnQzMihleGVjKTsKICAgICB1bnNpZ25lZCB0b3RhbFNp emUgPSBsZW5ndGggPyBsZW5ndGggLSAxIDogMDsKLSAgICBWZWN0b3I8UmVmUHRyPFVTdHJpbmc6 OlJlcD4sIDI1Nj4gc3RyQnVmZmVyKGxlbmd0aCk7CisgICAgVmVjdG9yPFJlZlB0cjxVU3RyaW5n OjpSZXA+ID4gc3RyQnVmZmVyKGxlbmd0aCk7CiAgICAgZm9yICh1bnNpZ25lZCBrID0gMDsgayA8 IGxlbmd0aDsgaysrKSB7CiAgICAgICAgIEpTVmFsdWUgZWxlbWVudDsKICAgICAgICAgaWYgKGlz UmVhbEFycmF5ICYmIHRoaXNPYmotPmNhbkdldEluZGV4KGspKQo= 58798 2010-06-15 11:10:45 -0700 2010-06-15 11:10:45 -0700 Benchmark (test_page.html) test_page.html text/html 707 ostap73 PGh0bWw+CjxzY3JpcHQ+CmZ1bmN0aW9uIHRlc3RBcnJheSgpCnsKCXZhciBzdGFydFRpbWUgPSBu ZXcgRGF0ZSgpOwoJdmFyIGFyciA9IG5ldyBBcnJheSgpOwoJdHJ5IHsKCQlmb3IgKHZhciBpPTA7 IGk8PTI1NTsgKytpKSAvL3RoZSB0b3N0cmluZygpIHN0YWNrIGRlcHRoIG9mIHRoZSBtYWludGhy ZWFkIGNhbiBub3QgZXhjZWVkIDI1NgoJCQlhcnIucHVzaChpKTsKCQlmb3IgKHZhciBpPTA7IGk8 PWFyci5sZW5ndGg7ICsraSkgewoJCQlhcnIuc29ydCgpOwoJCQlhcnIucHVzaChhcnIuc3BsaWNl KDAsIDEpKTsKCQl9Cgl9IGNhdGNoIChlKSB7CgkJYWxlcnQoZS50b1N0cmluZygpKTsKCX0KCXZh ciBleGVjVGltZSA9IG5ldyBEYXRlKCkgLSBzdGFydFRpbWU7CglyZXR1cm4gZXhlY1RpbWU7Cn0K CmZ1bmN0aW9uIHRlc3QoKSAKewoJdmFyIGRpdjEgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgi ZGl2MSIpOwoJdmFyIHRlc3RSZXN1bHQgPSAwOwoJZm9yICh2YXIgaT0wOyBpPDEwMDsgKytpKSB7 CgkJdGVzdFJlc3VsdCArPSB0ZXN0QXJyYXkoKTsKCX0KCWRpdjEuaW5uZXJIVE1MID0gdGVzdFJl c3VsdC8xMDA7Cn0KPC9zY3JpcHQ+Cjxib2R5IG9ubG9hZD0idGVzdCgpIj4KPGRpdiBpZD0iZGl2 MSI+PC9kaXY+CjxpbnB1dCB0eXBlPSJidXR0b24iIHZhbHVlPSJ0ZXN0IiBvbmNsaWNrPSJ0ZXN0 KCkiIC8+CjwvYm9keT4KPC9odG1sPgo= 62296 2010-07-22 07:45:40 -0700 2010-09-18 03:19:48 -0700 Symbian only patch CelticKaneFix02.diff text/plain 1382 ostap73 SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDYzNjgxKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTAtMDctMjIgIFZpYXRjaGVz bGF2IE9zdGFwZW5rbyAgPG9zdGFwZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgW1F0XSBTdGFjayBvdmVy ZmxvdyBvbiBzeW1iaWFuIHBsYXRmb3JtLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9NDA1OTgKKyAgICAgICAgCisgICAgICAgIE1vdmUgYmlnIGFsbG9j YXRpb24gaW4gYXJyYXlQcm90b0Z1bmNUb1N0cmluZyBmcm9tIHN0YWNrIHRvIGhlYXAuCisKKyAg ICAgICAgKiBydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcDoKKyAgICAgICAgKEpTQzo6YXJyYXlQ cm90b0Z1bmNUb1N0cmluZyk6CisKIDIwMTAtMDctMTYgIERhcmluIEFkbGVyICA8ZGFyaW5AYXBw bGUuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IFNhbSBXZWluaWcuCkluZGV4OiBKYXZhU2Ny aXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2Ny aXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAkocmV2aXNpb24gNjM2ODEpCisrKyBK YXZhU2NyaXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBlLmNwcAkod29ya2luZyBjb3B5KQpA QCAtMTY2LDcgKzE2NiwxMSBAQCBFbmNvZGVkSlNWYWx1ZSBKU0NfSE9TVF9DQUxMIGFycmF5UHJv dG9GCiAKICAgICB1bnNpZ25lZCBsZW5ndGggPSB0aGlzT2JqLT5nZXQoZXhlYywgZXhlYy0+cHJv cGVydHlOYW1lcygpLmxlbmd0aCkudG9VSW50MzIoZXhlYyk7CiAgICAgdW5zaWduZWQgdG90YWxT aXplID0gbGVuZ3RoID8gbGVuZ3RoIC0gMSA6IDA7CisjaWYgT1MoU1lNQklBTikKKyAgICBWZWN0 b3I8UmVmUHRyPFVTdHJpbmc6OlJlcD4gPiBzdHJCdWZmZXIobGVuZ3RoKTsKKyNlbHNlCiAgICAg VmVjdG9yPFJlZlB0cjxVU3RyaW5nOjpSZXA+LCAyNTY+IHN0ckJ1ZmZlcihsZW5ndGgpOworI2Vu ZGlmCiAgICAgZm9yICh1bnNpZ25lZCBrID0gMDsgayA8IGxlbmd0aDsgaysrKSB7CiAgICAgICAg IEpTVmFsdWUgZWxlbWVudDsKICAgICAgICAgaWYgKGlzUmVhbEFycmF5ICYmIHRoaXNPYmotPmNh bkdldEluZGV4KGspKQo= 67831 2010-09-16 12:47:59 -0700 2010-10-01 07:56:30 -0700 Added comment about symbian stack CelticKaneFix03.diff text/plain 1766 ostap73 SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDY3NjQwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTggQEAKKzIwMTAtMDktMTYgIFZpYXRjaGVz bGF2IE9zdGFwZW5rbyAgPG9zdGFwZW5rby52aWF0Y2hlc2xhdkBub2tpYS5jb20+CisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgW1F0XSBTdGFjayBvdmVy ZmxvdyBvbiBzeW1iaWFuIHBsYXRmb3JtLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9NDA1OTgKKyAgICAgICAgCisgICAgICAgIE1vdmUgYmlnIGFsbG9j YXRpb24gaW4gYXJyYXlQcm90b0Z1bmNUb1N0cmluZyBmcm9tIHN0YWNrIHRvIGhlYXAuCisgICAg ICAgIEpTQzo6YXJyYXlQcm90b0Z1bmNUb1N0cmluZyBmdW5jdGlvbiBjYW4gYmUgY2FsbGVkIHJl Y3Vyc2l2bHkgYW5kCisgICAgICAgIDFLIGFsbG9jYXRpb24gb24gc3RhY2sgY2Foc2Ugc3RhY2sg b3ZlcmZsb3cuCisgICAgICAgIENhbiBiZSB1c2VmdWwgZm9yIG90aGVyIHBsYXRmb3JtcyB3aXRo IGxpbWl0ZWQgc3RhY2sgc2l6ZS4KKworICAgICAgICAqIHJ1bnRpbWUvQXJyYXlQcm90b3R5cGUu Y3BwOgorICAgICAgICAoSlNDOjphcnJheVByb3RvRnVuY1RvU3RyaW5nKToKKwogMjAxMC0wOS0x NiAgRXJpYyBVaHJoYW5lICA8ZXJpY3VAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJldmlld2Vk IGJ5IEppYW4gTGkuCkluZGV4OiBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBl LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0FycmF5UHJvdG90eXBl LmNwcAkocmV2aXNpb24gNjc2NDApCisrKyBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0FycmF5UHJv dG90eXBlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTgwLDcgKzE4MCwxNCBAQCBFbmNvZGVkSlNW YWx1ZSBKU0NfSE9TVF9DQUxMIGFycmF5UHJvdG9GCiAKICAgICB1bnNpZ25lZCBsZW5ndGggPSB0 aGlzT2JqLT5nZXQoZXhlYywgZXhlYy0+cHJvcGVydHlOYW1lcygpLmxlbmd0aCkudG9VSW50MzIo ZXhlYyk7CiAgICAgdW5zaWduZWQgdG90YWxTaXplID0gbGVuZ3RoID8gbGVuZ3RoIC0gMSA6IDA7 CisjaWYgT1MoU1lNQklBTikKKyAgICAvLyBTeW1iaWFuIGhhcyB2ZXJ5IGxpbWl0ZWQgc3RhY2sg c2l6ZSBhdmFpbGFibGUuCisgICAgLy8gVGhpcyBmdW5jdGlvbiBjb3VsZCBiZSBjYWxsZWQgcmVj dXJzaXZlbHkgYW5kIGFsbG9jYXRpbmcgMUsgb24gc3RhY2sgaGVyZSBjYXVzZQorICAgIC8vIHN0 YWNrIG92ZXJmbG93IG9uIFN5bWJpYW4gZGV2aWNlcy4KKyAgICBWZWN0b3I8UmVmUHRyPFN0cmlu Z0ltcGw+ID4gc3RyQnVmZmVyKGxlbmd0aCk7CisjZWxzZQogICAgIFZlY3RvcjxSZWZQdHI8U3Ry aW5nSW1wbD4sIDI1Nj4gc3RyQnVmZmVyKGxlbmd0aCk7CisjZW5kaWYgICAgCiAgICAgZm9yICh1 bnNpZ25lZCBrID0gMDsgayA8IGxlbmd0aDsgaysrKSB7CiAgICAgICAgIEpTVmFsdWUgZWxlbWVu dDsKICAgICAgICAgaWYgKGlzUmVhbEFycmF5ICYmIHRoaXNPYmotPmNhbkdldEluZGV4KGspKQo=