145385 2015-05-26 13:35:33 -0700 Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf) 2015-06-29 18:36:37 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 ggaren ggaren cgarcia clopez kling mario mcatanzaro mrobinson oliver tpopela oldest_to_newest 1097405 0 ggaren 2015-05-26 13:35:33 -0700 Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf) 1097411 1 253729 ggaren 2015-05-26 13:41:01 -0700 Created attachment 253729 Patch 1097418 2 253729 msaboff 2015-05-26 13:50:57 -0700 Comment on attachment 253729 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=253729&action=review > Source/bmalloc/bmalloc/Allocator.cpp:112 > + size = roundUpToMultipleOf<xLargeAlignment>(size); > + alignment = std::max(superChunkSize, alignment); Since superChunkSize(32MB) is larger than xLargeAlignment (page size), Isn't it possible for the size of an aligned extra large allocation to overflow? 1097421 3 ggaren 2015-05-26 13:53:30 -0700 > Since superChunkSize(32MB) is larger than xLargeAlignment (page size), Isn't > it possible for the size of an aligned extra large allocation to overflow? Which line of code do you think will overflow? In the XLarge case, we don't do math on xLargeAlignment -- we just pass it through to the kernel. As long as there's no bug in the kernel, we should be OK. 1097511 4 253729 kling 2015-05-26 15:44:01 -0700 Comment on attachment 253729 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=253729&action=review r=me > Source/bmalloc/bmalloc/Allocator.cpp:64 > + return PerProcess<Heap>::get()->tryAllocateXLarge(lock, superChunkSize, roundUpToMultipleOf<xLargeAlignment>(size)); Can use getFastCase() here. 1097513 5 ggaren 2015-05-26 15:48:27 -0700 Committed r184883: <http://trac.webkit.org/changeset/184883> 1105279 6 mcatanzaro 2015-06-28 08:35:31 -0700 In Fedora we have 105 reports of this crash still occurring in our latest build with this patch applied (all from 32-bit computers), so something's still wrong here. 1105360 7 mario 2015-06-29 02:56:14 -0700 (In reply to comment #6) > In Fedora we have 105 reports of this crash still occurring in our latest > build with this patch applied (all from 32-bit computers), so something's > still wrong here. I've seen this since last week in our debian-like Linux system too, right after upgrading to WebKitGTK+ 2.8.3. I've applied the patch here but the crash is not gone yet, still trying to find what's wrong here. Will report back as soon as I have more info. 1105419 8 ggaren 2015-06-29 10:47:20 -0700 Which crash? 1105424 9 oliver 2015-06-29 10:58:56 -0700 Can someone who's seeing this crash put a stack trace in? Preferably with local var info if you can get it. 1105425 10 mrobinson 2015-06-29 11:00:57 -0700 (In reply to comment #8) > Which crash? I think Mario is referring to the crash discussed here: https://lists.webkit.org/pipermail/webkit-gtk/2015-June/002381.html The stack trace for that one is: (gdb) bt #0 allocateXLarge () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Heap.cpp:287 #1 0xb4fc94f5 in allocateXLarge () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Heap.cpp:293 #2 0xb4fc6ac4 in allocateXLarge () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.cpp:227 #3 0xb4fc6b2e in allocateSlowCase () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.cpp:245 #4 0xb4f95de2 in allocate () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.h:86 #5 allocate () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Cache.h:79 #6 malloc () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/bmalloc.h:43 #7 fastMalloc () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/FastMalloc.cpp:270 #8 0xb5592815 in allocateBuffer () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:269 #9 reserveCapacity () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1090 #10 expandCapacity () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:951 #11 0xb5f766e1 in expandCapacity () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:958 #12 appendSlowCase<WebCore::FloatRect&> () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1219 #13 append<WebCore::FloatRect&> () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1210 #14 createOrDestroyTilesIfNeeded () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/TextureMapperTiledBackingStore.cpp:89 #15 0xb5f77001 in updateContents () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/TextureMapperTiledBackingStore.cpp:148 #16 0xb64aefb3 in updateBackingStoreIfNeeded () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:549 #17 0xb64af095 in updateBackingStoreIncludingSubLayers () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:519 #18 0xb64af0ed in updateBackingStoreIncludingSubLayers () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:526 #19 0xb64af0ed in updateBackingStoreIncludingSubLayers () at /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:526 [...] 1105441 11 clopez 2015-06-29 11:57:58 -0700 The report on RH bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1225733 https://retrace.fedoraproject.org/faf/reports/605326/ 1105451 12 mcatanzaro 2015-06-29 12:08:32 -0700 (In reply to comment #8) > Which crash? Eh, the Fedora crash report was thought to be caused by this bug, but I see there is no report of any crash in this bug. We could create a separate WebKit bug report for this if you want. We usually always have a full backtrace with local variable info (for whichever variables survived optimization) but this time around we don't, due to a flaw in the Fedora crash tracker. Maybe Mario can provide that, since he can reproduce it reliably. 1105473 13 ggaren 2015-06-29 13:20:54 -0700 That crash is not related to integer overflow. 1105484 14 mario 2015-06-29 13:50:22 -0700 (In reply to comment #12) > (In reply to comment #8) > > Which crash? > Sorry about that, I've been trying to wrap my head today around so many things that I reply too quickly, without actually realizing that this bug was not about any crash :/ In any case, I was referring to the crash that Martin kindly pasted here, which I've been reliably reproducing 100% of the times in my Ubuntu-like 32-bit box whenever I run an application that embeds and uses WebKitGTK+ through GObject Introspection (more details here: https://lists.webkit.org/pipermail/webkit-gtk/2015-June/002381.html) > Eh, the Fedora crash report was thought to be caused by this bug, but I see > there is no report of any crash in this bug. We could create a separate > WebKit bug report for this if you want. > Same here. I also thought that this crash could have be caused by the same issue, and therefore I also associated it somehow with this patch. But perhaps is not related, as Geoffrey mentioned in his last comment. I'll file a new bug then, now that it seems pretty obvious that is not only happening to me (the fedora backtrace is nearly identical)... > We usually always have a full backtrace with local variable info (for > whichever variables survived optimization) but this time around we don't, > due to a flaw in the Fedora crash tracker. Maybe Mario can provide that, > since he can reproduce it reliably. Not this time, sorry. The backtrace you are seeing now is the best that I could get so far, which is taken out of a DEBUG build with -O0 and -g1 passed as CFLAGS. I'd love to have passed -g2 or -g3, so that I can get the actual values in the backtrace, but I haven't found a way to do it because, being a 32-bit build, whenever I get to the linking stage the building process dies trying to link 2.4GB of shared objects. If you, or anyone else, knows a way I can still get a more meaningful backtrace for this 32-bit build, I'm more than extremely happy to try that out, so please speak up :) (In reply to comment #13) > That crash is not related to integer overflow. Thanks for confirming that. Any idea on what this could be a about then? 1105560 15 mario 2015-06-29 16:41:35 -0700 (In reply to comment #14) > [...] > I'll file a new bug then, now that it seems pretty obvious that is not only > happening to me (the fedora backtrace is nearly identical)... New bug reported: https://bugs.webkit.org/show_bug.cgi?id=146440 253729 2015-05-26 13:41:01 -0700 2015-05-26 15:44:01 -0700 Patch bug-145385-20150526134051.patch text/plain 5599 ggaren SW5kZXg6IFNvdXJjZS9ibWFsbG9jL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvYm1h bGxvYy9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NDg2OSkKKysrIFNvdXJjZS9ibWFsbG9jL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDM0IEBACisyMDE1LTA1LTI2ICBHZW9mZnJl eSBHYXJlbiAgPGdnYXJlbkBhcHBsZS5jb20+CisKKyAgICAgICAgSW50ZWdlciBvdmVyZmxvdyBp biBYTGFyZ2UgYWxsb2NhdGlvbiAoZHVlIHRvIHVuY2hlY2tlZCByb3VuZFVwVG9NdWx0aXBsZU9m KQorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTQ1Mzg1 CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkZWQg c29tZSBjaGVja2luZyB0byB2ZXJpZnkgdGhhdCByb3VuZC11cCBvcGVyYXRpb25zIHdpbGwgbm90 IG92ZXJmbG93CisgICAgICAgIGEgc2l6ZV90LgorCisgICAgICAgIFRoZSBzaW1wbGVzdCB3YXkg dG8gZG8gdGhpcyB3YXMgdG8gaW50cm9kdWNlIGEgbm90aW9uIG9mIHhMYXJnZU1heCwgbGlrZQor ICAgICAgICB3ZSBoYXZlIGZvciBzbWFsbE1heCwgbWVkaXVtTWF4LCBhbmQgbGFyZ2VNYXguIEl0 J3MgYSBiaXQgc3VycHJpc2luZyBhdAorICAgICAgICBmaXJzdCB0byB0aGluayB0aGF0IHRoZXJl IGlzIGFuIHhMYXJnZU1heCwgc2luY2UgeExhcmdlIGlzIHdoYXQgd2UgdXNlCisgICAgICAgIHRv IGhhbmRsZSB0aGUgYmlnZ2VzdCB0aGluZ3MuIEJ1dCBjb21wdXRlcnMgaGF2ZSBsaW1pdHMsIHNv IGl0IG1ha2VzIHNlbnNlLgorCisgICAgICAgIEZXSVcsIFRDTWFsbG9jIHVzZWQgdG8gaGF2ZSBh biB4TGFyZ2VNYXggdG9vLCB3aGljaCBpdCBjYWxsZWQga01heFZhbGlkUGFnZXMuCisKKyAgICAg ICAgTm8gdGVzdCBiZWNhdXNlIHRoaXMgYnVnIHdhcyBmb3VuZCBieSBjb2RlIGluc3BlY3Rpb24g YW5kIEkgZG9uJ3Qga25vdworICAgICAgICBvZiBhIHByYWN0aWNhbCB3YXkgdG8gY29udmluY2Ug V2ViS2l0IHRvIG1ha2UgYW4gYWxsb2NhdGlvbiB0aGlzIGxhcmdlLgorCisgICAgICAgICogYm1h bGxvYy9BbGxvY2F0b3IuY3BwOgorICAgICAgICAoYm1hbGxvYzo6QWxsb2NhdG9yOjp0cnlBbGxv Y2F0ZSk6CisgICAgICAgIChibWFsbG9jOjpBbGxvY2F0b3I6OmFsbG9jYXRlKToKKyAgICAgICAg KGJtYWxsb2M6OkFsbG9jYXRvcjo6cmVhbGxvY2F0ZSk6CisgICAgICAgIChibWFsbG9jOjpBbGxv Y2F0b3I6OmFsbG9jYXRlU2xvd0Nhc2UpOiBDaGVjayBhZ2FpbnN0IHhMYXJnZU1heCB0byBhdm9p ZAorICAgICAgICBvdmVyZmxvdyB3aGVuIHJvdW5kaW5nIHVwLgorCisgICAgICAgICogYm1hbGxv Yy9CQXNzZXJ0Lmg6IEFkZGVkIHN1cHBvcnQgZm9yIGV4cGxpY2l0IGNyYXNoaW5nLgorCisgICAg ICAgICogYm1hbGxvYy9TaXplcy5oOgorCiAyMDE1LTA1LTI2ICBEYW4gQmVybnN0ZWluICA8bWl0 ekBhcHBsZS5jb20+CiAKICAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzIxMTA0NTUxPiBVcGRhdGUg YnVpbGQgc2V0dGluZ3MKSW5kZXg6IFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvQWxsb2NhdG9yLmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvYm1hbGxvYy9ibWFsbG9jL0FsbG9jYXRvci5jcHAJKHJl dmlzaW9uIDE4NDg2MikKKysrIFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvQWxsb2NhdG9yLmNwcAko d29ya2luZyBjb3B5KQpAQCAtNTksOCArNTksMTIgQEAgdm9pZCogQWxsb2NhdG9yOjp0cnlBbGxv Y2F0ZShzaXplX3Qgc2l6ZQogICAgIGlmIChzaXplIDw9IGxhcmdlTWF4KQogICAgICAgICByZXR1 cm4gYWxsb2NhdGUoc2l6ZSk7CiAKLSAgICBzdGQ6OmxvY2tfZ3VhcmQ8U3RhdGljTXV0ZXg+IGxv Y2soUGVyUHJvY2VzczxIZWFwPjo6bXV0ZXgoKSk7Ci0gICAgcmV0dXJuIFBlclByb2Nlc3M8SGVh cD46OmdldCgpLT50cnlBbGxvY2F0ZVhMYXJnZShsb2NrLCBzdXBlckNodW5rU2l6ZSwgcm91bmRV cFRvTXVsdGlwbGVPZjx4TGFyZ2VBbGlnbm1lbnQ+KHNpemUpKTsKKyAgICBpZiAoc2l6ZSA8PSB4 TGFyZ2VNYXgpIHsKKyAgICAgICAgc3RkOjpsb2NrX2d1YXJkPFN0YXRpY011dGV4PiBsb2NrKFBl clByb2Nlc3M8SGVhcD46Om11dGV4KCkpOworICAgICAgICByZXR1cm4gUGVyUHJvY2VzczxIZWFw Pjo6Z2V0KCktPnRyeUFsbG9jYXRlWExhcmdlKGxvY2ssIHN1cGVyQ2h1bmtTaXplLCByb3VuZFVw VG9NdWx0aXBsZU9mPHhMYXJnZUFsaWdubWVudD4oc2l6ZSkpOworICAgIH0KKworICAgIHJldHVy biBudWxscHRyOwogfQogCiB2b2lkKiBBbGxvY2F0b3I6OmFsbG9jYXRlKHNpemVfdCBhbGlnbm1l bnQsIHNpemVfdCBzaXplKQpAQCAtOTMsMTggKzk3LDI1IEBAIHZvaWQqIEFsbG9jYXRvcjo6YWxs b2NhdGUoc2l6ZV90IGFsaWdubWUKICAgICAgICAgfQogICAgIH0KIAotICAgIHNpemUgPSBzdGQ6 Om1heChsYXJnZU1pbiwgcm91bmRVcFRvTXVsdGlwbGVPZjxsYXJnZUFsaWdubWVudD4oc2l6ZSkp OwotICAgIGFsaWdubWVudCA9IHJvdW5kVXBUb011bHRpcGxlT2Y8bGFyZ2VBbGlnbm1lbnQ+KGFs aWdubWVudCk7Ci0gICAgc2l6ZV90IHVuYWxpZ25lZFNpemUgPSBsYXJnZU1pbiArIGFsaWdubWVu dCArIHNpemU7Ci0gICAgaWYgKHVuYWxpZ25lZFNpemUgPD0gbGFyZ2VNYXggJiYgYWxpZ25tZW50 IDw9IGxhcmdlQ2h1bmtTaXplIC8gMikgeworICAgIGlmIChzaXplIDw9IGxhcmdlTWF4ICYmIGFs aWdubWVudCA8PSBsYXJnZU1heCkgeworICAgICAgICBzaXplID0gc3RkOjptYXgobGFyZ2VNaW4s IHJvdW5kVXBUb011bHRpcGxlT2Y8bGFyZ2VBbGlnbm1lbnQ+KHNpemUpKTsKKyAgICAgICAgYWxp Z25tZW50ID0gcm91bmRVcFRvTXVsdGlwbGVPZjxsYXJnZUFsaWdubWVudD4oYWxpZ25tZW50KTsK KyAgICAgICAgc2l6ZV90IHVuYWxpZ25lZFNpemUgPSBsYXJnZU1pbiArIGFsaWdubWVudCArIHNp emU7CisgICAgICAgIGlmICh1bmFsaWduZWRTaXplIDw9IGxhcmdlTWF4ICYmIGFsaWdubWVudCA8 PSBsYXJnZUNodW5rU2l6ZSAvIDIpIHsKKyAgICAgICAgICAgIHN0ZDo6bG9ja19ndWFyZDxTdGF0 aWNNdXRleD4gbG9jayhQZXJQcm9jZXNzPEhlYXA+OjptdXRleCgpKTsKKyAgICAgICAgICAgIHJl dHVybiBQZXJQcm9jZXNzPEhlYXA+OjpnZXRGYXN0Q2FzZSgpLT5hbGxvY2F0ZUxhcmdlKGxvY2ss IGFsaWdubWVudCwgc2l6ZSwgdW5hbGlnbmVkU2l6ZSk7CisgICAgICAgIH0KKyAgICB9CisKKyAg ICBpZiAoc2l6ZSA8PSB4TGFyZ2VNYXggJiYgYWxpZ25tZW50IDw9IHhMYXJnZU1heCkgeworICAg ICAgICBzaXplID0gcm91bmRVcFRvTXVsdGlwbGVPZjx4TGFyZ2VBbGlnbm1lbnQ+KHNpemUpOwor ICAgICAgICBhbGlnbm1lbnQgPSBzdGQ6Om1heChzdXBlckNodW5rU2l6ZSwgYWxpZ25tZW50KTsK ICAgICAgICAgc3RkOjpsb2NrX2d1YXJkPFN0YXRpY011dGV4PiBsb2NrKFBlclByb2Nlc3M8SGVh cD46Om11dGV4KCkpOwotICAgICAgICByZXR1cm4gUGVyUHJvY2VzczxIZWFwPjo6Z2V0RmFzdENh c2UoKS0+YWxsb2NhdGVMYXJnZShsb2NrLCBhbGlnbm1lbnQsIHNpemUsIHVuYWxpZ25lZFNpemUp OworICAgICAgICByZXR1cm4gUGVyUHJvY2VzczxIZWFwPjo6Z2V0RmFzdENhc2UoKS0+YWxsb2Nh dGVYTGFyZ2UobG9jaywgYWxpZ25tZW50LCBzaXplKTsKICAgICB9CiAKLSAgICBzaXplID0gcm91 bmRVcFRvTXVsdGlwbGVPZjx4TGFyZ2VBbGlnbm1lbnQ+KHNpemUpOwotICAgIGFsaWdubWVudCA9 IHN0ZDo6bWF4KHN1cGVyQ2h1bmtTaXplLCBhbGlnbm1lbnQpOwotICAgIHN0ZDo6bG9ja19ndWFy ZDxTdGF0aWNNdXRleD4gbG9jayhQZXJQcm9jZXNzPEhlYXA+OjptdXRleCgpKTsKLSAgICByZXR1 cm4gUGVyUHJvY2VzczxIZWFwPjo6Z2V0RmFzdENhc2UoKS0+YWxsb2NhdGVYTGFyZ2UobG9jaywg YWxpZ25tZW50LCBzaXplKTsKKyAgICBCQ1JBU0goKTsKKyAgICByZXR1cm4gbnVsbHB0cjsKIH0K IAogdm9pZCogQWxsb2NhdG9yOjpyZWFsbG9jYXRlKHZvaWQqIG9iamVjdCwgc2l6ZV90IG5ld1Np emUpCkBAIC0yNDIsNyArMjUzLDExIEBAIHZvaWQqIEFsbG9jYXRvcjo6YWxsb2NhdGVTbG93Q2Fz ZShzaXplX3QKICAgICBpZiAoc2l6ZSA8PSBsYXJnZU1heCkKICAgICAgICAgcmV0dXJuIGFsbG9j YXRlTGFyZ2Uoc2l6ZSk7CiAKLSAgICByZXR1cm4gYWxsb2NhdGVYTGFyZ2Uoc2l6ZSk7CisgICAg aWYgKHNpemUgPD0geExhcmdlTWF4KQorICAgICAgICByZXR1cm4gYWxsb2NhdGVYTGFyZ2Uoc2l6 ZSk7CisKKyAgICBCQ1JBU0goKTsKKyAgICByZXR1cm4gbnVsbHB0cjsKIH0KIAogfSAvLyBuYW1l c3BhY2UgYm1hbGxvYwpJbmRleDogU291cmNlL2JtYWxsb2MvYm1hbGxvYy9CQXNzZXJ0LmgKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gU291cmNlL2JtYWxsb2MvYm1hbGxvYy9CQXNzZXJ0LmgJKHJldmlzaW9uIDE4 NDg2MikKKysrIFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvQkFzc2VydC5oCSh3b3JraW5nIGNvcHkp CkBAIC0yNiwxMCArMjYsMTQgQEAKICNpZm5kZWYgQkFzc2VydF9oCiAjZGVmaW5lIEJBc3NlcnRf aAogCisjZGVmaW5lIEJDUkFTSCgpIGRvIHsgXAorICAgICooaW50KikweGJiYWRiZWVmID0gMDsg XAorfSB3aGlsZSAoMCk7CisKICNkZWZpbmUgQkFTU0VSVF9JTVBMKHgpIGRvIHsgXAogICAgIGlm ICghKHgpKSBcCi0gICAgICAgICooaW50KikweGJiYWRiZWVmID0gMDsgXAotfSB3aGlsZSgwKTsK KyAgICAgICAgQkNSQVNIKCk7IFwKK30gd2hpbGUgKDApOwogCiAjZGVmaW5lIFJFTEVBU0VfQkFT U0VSVCh4KSBCQVNTRVJUX0lNUEwoeCkKIApJbmRleDogU291cmNlL2JtYWxsb2MvYm1hbGxvYy9T aXplcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvU2l6ZXMuaAkocmV2 aXNpb24gMTg0ODYyKQorKysgU291cmNlL2JtYWxsb2MvYm1hbGxvYy9TaXplcy5oCSh3b3JraW5n IGNvcHkpCkBAIC04MCw2ICs4MCw3IEBAIG5hbWVzcGFjZSBTaXplcyB7CiAgICAgc3RhdGljIGNv bnN0IHNpemVfdCBsYXJnZU1pbiA9IG1lZGl1bU1heDsKICAgICAKICAgICBzdGF0aWMgY29uc3Qg c2l6ZV90IHhMYXJnZUFsaWdubWVudCA9IHZtUGFnZVNpemU7CisgICAgc3RhdGljIGNvbnN0IHNp emVfdCB4TGFyZ2VNYXggPSBzdGQ6Om51bWVyaWNfbGltaXRzPHNpemVfdD46Om1heCgpIC0geExh cmdlQWxpZ25tZW50OyAvLyBNYWtlIHN1cmUgdGhhdCByb3VuZGluZyB1cCB0byB4TGFyZ2VBbGln bm1lbnQgZG9lcyBub3Qgb3ZlcmZsb3cuCiAKICAgICBzdGF0aWMgY29uc3Qgc2l6ZV90IGZyZWVM aXN0U2VhcmNoRGVwdGggPSAxNjsKICAgICBzdGF0aWMgY29uc3Qgc2l6ZV90IGZyZWVMaXN0R3Jv d0ZhY3RvciA9IDI7Cg==