80165 2012-03-02 09:05:38 -0800 [Qt][WK2] Crash in Frame.cpp when loading index.hu 2012-03-06 09:58:06 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All Linux RESOLVED FIXED P2 Major --- 80294 1 abecsi allan.jensen allan.jensen ap hausmann jturcotte kenneth manyoso tonikitoo webkit.review.bot zalan oldest_to_newest 569686 0 abecsi 2012-03-02 09:05:38 -0800 When loading the news site index.hu in Qt MiniBrowser the suspending code introduced in r109548 tries to call a methond on a null pointer in Source/WebCore/page/Frame.cpp:318. 0x00007ffff5042184 in WebCore::Frame::setDocument (this=0x1c0fd90, newDoc=...) at ../../../../Source/WebCore/page/Frame.cpp:318 318 document()->suspendScriptedAnimationControllerCallbacks(); (gdb) bt #0 0x00007ffff5042184 in WebCore::Frame::setDocument (this=0x1c0fd90, newDoc=...) at ../../../../Source/WebCore/page/Frame.cpp:318 #1 0x00007ffff4f8919c in WebCore::FrameLoader::clear (this=0x1c0fe50, clearWindowProperties=true, clearScriptObjects=true, clearFrameView=true) at ../../../../Source/WebCore/loader/FrameLoader.cpp:548 #2 0x00007ffff4f82d8b in WebCore::DocumentWriter::begin (this=0x1c17050, urlReference=..., dispatch=false, ownerDocument=0x0) at ../../../../Source/WebCore/loader/DocumentWriter.cpp:128 #3 0x00007ffff4f89329 in WebCore::FrameLoader::receivedFirstData (this=0x1c0fe50) at ../../../../Source/WebCore/loader/FrameLoader.cpp:576 #4 0x00007ffff4f8b1ae in WebCore::FrameLoader::willSetEncoding (this=0x1c0fe50) at ../../../../Source/WebCore/loader/FrameLoader.cpp:989 #5 0x00007ffff4f8376c in WebCore::DocumentWriter::setEncoding (this=0x1c17050, name=..., userChosen=false) at ../../../../Source/WebCore/loader/DocumentWriter.cpp:239 #6 0x00007ffff4f774c1 in WebCore::DocumentLoader::commitData (this=0x1c16f30, bytes=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639) at ../../../../Source/WebCore/loader/DocumentLoader.cpp:325 #7 0x00007ffff47ecaf1 in WebKit::WebFrameLoaderClient::committedLoad (this=0x1c0f060, loader=0x1c16f30, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639) at ../../../../Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:839 #8 0x00007ffff4f773e0 in WebCore::DocumentLoader::commitLoad (this=0x1c16f30, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639) at ../../../../Source/WebCore/loader/DocumentLoader.cpp:313 #9 0x00007ffff4f77612 in WebCore::DocumentLoader::receivedData (this=0x1c16f30, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639) at ../../../../Source/WebCore/loader/DocumentLoader.cpp:339 #10 0x00007ffff4fab7eb in WebCore::MainResourceLoader::addData (this=0x1c218a0, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639, allAtOnce=false) at ../../../../Source/WebCore/loader/MainResourceLoader.cpp:170 #11 0x00007ffff4fb9544 in WebCore::ResourceLoader::didReceiveData (this=0x1c218a0, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639, encodedDataLength=-1, allAtOnce=false) at ../../../../Source/WebCore/loader/ResourceLoader.cpp:287 #12 0x00007ffff4fad03d in WebCore::MainResourceLoader::didReceiveData (this=0x1c218a0, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639, encodedDataLength=-1, allAtOnce=false) at ../../../../Source/WebCore/loader/MainResourceLoader.cpp:464 #13 0x00007ffff4fb9ecd in WebCore::ResourceLoader::didReceiveData (this=0x1c218a0, data=0x1580a78 "<html><head><title>Edigital :: </title><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n<!--[if lt IE 7]>\n<script language=\"JavaScript\">\nfunction correctPNG() // correctly handle PN"..., length=4639, encodedDataLength=-1) at ../../../../Source/WebCore/loader/ResourceLoader.cpp:441 #14 0x00007ffff53c487e in WebCore::QNetworkReplyHandler::forwardData (this=0x1c203e0) at ../../../../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:569 #15 0x00007ffff53c1b93 in WebCore::QNetworkReplyHandlerCallQueue::flush (this=0x1c20418) at ../../../../Source/WebCore/platform/network/qt/QNetworkReplyHandler.cpp:196 ... Null-checking document() before suspending naturally fixes the above issue but the same page ASSERTs in Source/WebCore/xml/XMLHttpRequestProgressEventThrottle.cpp:74 ASSERT(!suspended()) as soon as you start interacting with it. 569866 1 ap 2012-03-02 13:04:46 -0800 I cannot reproduce this in Safari (ToT WebKit). What does Qt do differently here? 570561 2 abecsi 2012-03-05 03:59:34 -0800 (In reply to comment #1) > I cannot reproduce this in Safari (ToT WebKit). What does Qt do differently here? I still see the crash in the web process with ToT WebKit and Qt MiniBrowser, so I'll mark this as a Qt specific bug. Judging from the stacktrace the bug could originate in the Qt networking stack. CCing people who might know what's going on here. 570627 3 allan.jensen 2012-03-05 06:28:33 -0800 This is apparently two different issues. The first one is a missing guard for m_doc in Frame::setDocument. The problem in XMLHttpRequest is deeper. The problem is the threaded loader can not be suspended, and this means progress events can still be emitted while the XMLHttpRequest object is suspended. XMLHttpRequest will set canSuspend() to false in this case, but that does not guarantee that it will not be asked to suspend anyway in some cases (for pageCache for instance). 570643 4 zalan 2012-03-05 06:48:45 -0800 so how did we end up with suspended frames while loading? Is it normal to see suspendActiveDOMObjectsAndAnimations() calls at this phase of constructing a page? 570664 5 allan.jensen 2012-03-05 07:09:53 -0800 (In reply to comment #4) > so how did we end up with suspended frames while loading? Is it normal to see suspendActiveDOMObjectsAndAnimations() calls at this phase of constructing a page? No, but if the page is loading continuously via xmlhttprequest, then it is inevitable we will end up with a suspended frame during a pan while a xmlhttprequest is running. 570670 6 zalan 2012-03-05 07:21:25 -0800 (In reply to comment #5) > (In reply to comment #4) > > so how did we end up with suspended frames while loading? Is it normal to see suspendActiveDOMObjectsAndAnimations() calls at this phase of constructing a page? > > No, but if the page is loading continuously via xmlhttprequest, then it is inevitable we will end up with a suspended frame during a pan while a xmlhttprequest is running. I can repro crash without any page interaction (panning, zooming) by just simply loading the page. 570694 7 allan.jensen 2012-03-05 07:53:37 -0800 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > so how did we end up with suspended frames while loading? Is it normal to see suspendActiveDOMObjectsAndAnimations() calls at this phase of constructing a page? > > > > No, but if the page is loading continuously via xmlhttprequest, then it is inevitable we will end up with a suspended frame during a pan while a xmlhttprequest is running. > > I can repro crash without any page interaction (panning, zooming) by just simply loading the page. I meant the second assertion we are seeing after guarding m_doc is triggered by page interaction. You are right though, the first one crash is actually a bit odd. It is a unset document call so probably during a redirection or reload of something in the page, but there still shouldn't be any calls suspending active-dom-objects before the users starts interacting with the page. It could be that flickable is interpreting some reported state-changes from the WebProcess as a user-input and starts animating them. 570705 8 zalan 2012-03-05 08:05:25 -0800 (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > so how did we end up with suspended frames while loading? Is it normal to see suspendActiveDOMObjectsAndAnimations() calls at this phase of constructing a page? > > > > > > No, but if the page is loading continuously via xmlhttprequest, then it is inevitable we will end up with a suspended frame during a pan while a xmlhttprequest is running. > > > > I can repro crash without any page interaction (panning, zooming) by just simply loading the page. > > I meant the second assertion we are seeing after guarding m_doc is triggered by page interaction. > > You are right though, the first one crash is actually a bit odd. It is a unset document call so probably during a redirection or reload of something in the page, but there still shouldn't be any calls suspending active-dom-objects before the users starts interacting with the page. > > It could be that flickable is interpreting some reported state-changes from the WebProcess as a user-input and starts animating them. Yea, could very well be. Before the if (document()) check is added (which seems to be checked everywhere in setDocument, so having null m_doc looks like a valid state), we should see why the suspend is triggered in this case. Having DOM objects suspended while loading (and resumed at some point) could potentially make complete load time longer. (so i guess in that sense, it's good that we've got this crash, otherwise it would have gone unnoticed) 570752 9 130148 allan.jensen 2012-03-05 09:03:43 -0800 Created attachment 130148 Patch 570754 10 zalan 2012-03-05 09:07:47 -0800 lgtm 570755 11 allan.jensen 2012-03-05 09:09:29 -0800 Finally for the problem in XMLHttpRequestProgressEventThrottle.cpp, something like the following solves the problem: void XMLHttpRequestProgressEventThrottle::dispatchEvent(PassRefPtr<Event> .. { - ASSERT(!suspended()); + if (suspended()) { + // Discard the current stored event and only store the latest. + m_pausedEvent = event; + return; + } The problem though is that this still loses progress events that the xmlhttprequest can emit while suspended. I can imagine cases where that might be a problem, though all regression-tests complete successfully. 570779 12 ap 2012-03-05 09:34:54 -0800 So the explanation of why this doesn't crash on Mac is that this is new Qt-only code, added in r109548. Please use a separate bug for the XMLHttpRequest issue. It seems possible that the concept of "suspend" introduced in r109548 is just not appropriate for WebKit though. 570786 13 tonikitoo 2012-03-05 09:41:53 -0800 (In reply to comment #12) > So the explanation of why this doesn't crash on Mac is that this is new Qt-only code, added in r109548. > > Please use a separate bug for the XMLHttpRequest issue. It seems possible that the concept of "suspend" introduced in r109548 is just not appropriate for WebKit though. Yes. We've ran into this before, and advised in the original bug. 570796 14 130148 menard 2012-03-05 09:53:09 -0800 Comment on attachment 130148 Patch Possible to write a test case for it? 570984 15 allan.jensen 2012-03-05 13:12:01 -0800 (In reply to comment #13) > (In reply to comment #12) > > So the explanation of why this doesn't crash on Mac is that this is new Qt-only code, added in r109548. > > > > Please use a separate bug for the XMLHttpRequest issue. It seems possible that the concept of "suspend" introduced in r109548 is just not appropriate for WebKit though. > > Yes. > > We've ran into this before, and advised in the original bug. That makes no sense. The bugs encountered here are independent of the new "type" of suspend, and existed with the existing suspend code. It was just harder to reproduce before and not triggered as often. So if nothing else this is exposing a range of tricky suspend bugs so they can be more easily fixed. 571024 16 130148 kenneth 2012-03-05 14:00:12 -0800 Comment on attachment 130148 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=130148&action=review > Source/WebCore/page/Frame.cpp:-320 > + m_doc->suspendScriptedAnimationControllerCallbacks(); > animation()->suspendAnimationsForDocument(document()); > - document()->suspendActiveDOMObjects(ActiveDOMObject::PageWillBeSuspended); One line uses document() (the line unchanged) others use m_doc, isn't it inline anyway? 571031 17 ap 2012-03-05 14:08:48 -0800 The preferred style is to use a member variable directly, not an accessor function. 571065 18 kenneth 2012-03-05 14:49:25 -0800 (In reply to comment #17) > The preferred style is to use a member variable directly, not an accessor function. OK, good to know. Then we should change it for the animation()->suspendAnimationsForDocument(document()); line as well. 571816 19 130374 allan.jensen 2012-03-06 07:02:41 -0800 Created attachment 130374 Patch 571935 20 130374 webkit.review.bot 2012-03-06 09:58:01 -0800 Comment on attachment 130374 Patch Clearing flags on attachment: 130374 Committed r109931: <http://trac.webkit.org/changeset/109931> 571936 21 webkit.review.bot 2012-03-06 09:58:06 -0800 All reviewed patches have been landed. Closing bug. 130148 2012-03-05 09:03:43 -0800 2012-03-06 07:02:33 -0800 Patch Patch1 text/plain 1565 allan.jensen ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCBhOGE1YTJjLi4yN2FiMWJjIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTYg QEAKKzIwMTItMDMtMDUgIEFsbGFuIFNhbmRmZWxkIEplbnNlbiAgPGFsbGFuLmplbnNlbkBub2tp YS5jb20+CisKKyAgICAgICAgW1F0XVtXSzJdIENyYXNoIGluIEZyYW1lLmNwcCB3aGVuIGxvYWRp bmcgaW5kZXguaHUKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTgwMTY1CisKKyAgICAgICAgR3VhcmQgYWdhaW5zdCBwb3NzaWJsZSBudWxsIGRvY3VtZW50 LCB3aGljaCBjYW4gaGFwcGVuCisgICAgICAgIHdoZW4gdW5zZXR0aW5nIGEgZG9jdW1lbnQgaW4g YSBmcmFtZS4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICAqIHBhZ2UvRnJhbWUuY3BwOgorICAgICAgICAoV2ViQ29yZTo6RnJhbWU6OnNldERvY3VtZW50 KToKKwogMjAxMi0wMy0wNSAgQWxleGFuZGVyIFBhdmxvdiAgPGFwYXZsb3ZAY2hyb21pdW0ub3Jn PgogCiAgICAgICAgIFdlYiBJbnNwZWN0b3I6IEluY29ycmVjdCBhcHByb3ByaWF0ZVNlbGVjdG9y Rm9yKCkgc3VnZ2VzdGlvbiBmb3Igd2hlbiBhIERPTU5vZGUgaGFzIG1vcmUgdGhhbiAyIENTUyBj bGFzc2VzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9wYWdlL0ZyYW1lLmNwcCBiL1NvdXJj ZS9XZWJDb3JlL3BhZ2UvRnJhbWUuY3BwCmluZGV4IGQ4MWUzYjcuLjdkYWVmYzcgMTAwNjQ0Ci0t LSBhL1NvdXJjZS9XZWJDb3JlL3BhZ2UvRnJhbWUuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3Bh Z2UvRnJhbWUuY3BwCkBAIC0zMTQsMTAgKzMxNCwxMCBAQCB2b2lkIEZyYW1lOjpzZXREb2N1bWVu dChQYXNzUmVmUHRyPERvY3VtZW50PiBuZXdEb2MpCiAgICAgfQogCiAgICAgLy8gU3VzcGVuZCBk b2N1bWVudCBpZiB0aGlzIGZyYW1lIHdhcyBjcmVhdGVkIGluIHN1c3BlbmRlZCBzdGF0ZS4KLSAg ICBpZiAoYWN0aXZlRE9NT2JqZWN0c0FuZEFuaW1hdGlvbnNTdXNwZW5kZWQoKSkgewotICAgICAg ICBkb2N1bWVudCgpLT5zdXNwZW5kU2NyaXB0ZWRBbmltYXRpb25Db250cm9sbGVyQ2FsbGJhY2tz KCk7CisgICAgaWYgKG1fZG9jICYmIGFjdGl2ZURPTU9iamVjdHNBbmRBbmltYXRpb25zU3VzcGVu ZGVkKCkpIHsKKyAgICAgICAgbV9kb2MtPnN1c3BlbmRTY3JpcHRlZEFuaW1hdGlvbkNvbnRyb2xs ZXJDYWxsYmFja3MoKTsKICAgICAgICAgYW5pbWF0aW9uKCktPnN1c3BlbmRBbmltYXRpb25zRm9y RG9jdW1lbnQoZG9jdW1lbnQoKSk7Ci0gICAgICAgIGRvY3VtZW50KCktPnN1c3BlbmRBY3RpdmVE T01PYmplY3RzKEFjdGl2ZURPTU9iamVjdDo6UGFnZVdpbGxCZVN1c3BlbmRlZCk7CisgICAgICAg IG1fZG9jLT5zdXNwZW5kQWN0aXZlRE9NT2JqZWN0cyhBY3RpdmVET01PYmplY3Q6OlBhZ2VXaWxs QmVTdXNwZW5kZWQpOwogICAgIH0KIH0KIAo= 130374 2012-03-06 07:02:41 -0800 2012-03-06 09:58:01 -0800 Patch bug-80165-20120306160239.patch text/plain 1752 allan.jensen U3VidmVyc2lvbiBSZXZpc2lvbjogMTA5OTE0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNDY4NDg5NmE4NmViMTVi MzQ0YWRkMDkwYjVlNDBkOGRhM2YzZjQ3Ni4uMjIzZGNkMDJiN2Q3N2FhZDgyMDIyMTI1MjlhMDlj Njk1ZjM3NTRiOCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDEyLTAzLTA2ICBBbGxh biBTYW5kZmVsZCBKZW5zZW4gIDxhbGxhbi5qZW5zZW5Abm9raWEuY29tPgorCisgICAgICAgIFtR dF1bV0syXSBDcmFzaCBpbiBGcmFtZS5jcHAgd2hlbiBsb2FkaW5nIGluZGV4Lmh1CisgICAgICAg IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD04MDE2NQorCisgICAgICAg IEd1YXJkIGFnYWluc3QgcG9zc2libGUgbnVsbCBkb2N1bWVudCwgd2hpY2ggY2FuIGhhcHBlbgor ICAgICAgICB3aGVuIHVuc2V0dGluZyBhIGRvY3VtZW50IGluIGEgZnJhbWUuCisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBwYWdlL0ZyYW1lLmNwcDoK KyAgICAgICAgKFdlYkNvcmU6OkZyYW1lOjpzZXREb2N1bWVudCk6CisKIDIwMTItMDMtMDYgIEFs ZXhhbmRlciBGw6Zyw7h5ICA8YWxleGFuZGVyLmZhZXJveUBub2tpYS5jb20+CiAKICAgICAgICAg UmVuYW1lIG1fdGlsZUNyZWF0aW9uVGltZXIgaW4gdGhlIHRpbGVkIGJhY2tpbmcgc3RvcmUKZGlm ZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3BhZ2UvRnJhbWUuY3BwIGIvU291cmNlL1dlYkNvcmUv cGFnZS9GcmFtZS5jcHAKaW5kZXggZDgxZTNiNzQ4MWQyZWU0N2MxZWNhZjBlYjRmYmViOWZlYTUy YjI0NS4uYWQ5Y2FiOGU5ZDEzYTFmNWJiNzU4MzE3YmJjNzk2MjNjYmU2YWM0MCAxMDA2NDQKLS0t IGEvU291cmNlL1dlYkNvcmUvcGFnZS9GcmFtZS5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGFn ZS9GcmFtZS5jcHAKQEAgLTMxNCwxMCArMzE0LDEwIEBAIHZvaWQgRnJhbWU6OnNldERvY3VtZW50 KFBhc3NSZWZQdHI8RG9jdW1lbnQ+IG5ld0RvYykKICAgICB9CiAKICAgICAvLyBTdXNwZW5kIGRv Y3VtZW50IGlmIHRoaXMgZnJhbWUgd2FzIGNyZWF0ZWQgaW4gc3VzcGVuZGVkIHN0YXRlLgotICAg IGlmIChhY3RpdmVET01PYmplY3RzQW5kQW5pbWF0aW9uc1N1c3BlbmRlZCgpKSB7Ci0gICAgICAg IGRvY3VtZW50KCktPnN1c3BlbmRTY3JpcHRlZEFuaW1hdGlvbkNvbnRyb2xsZXJDYWxsYmFja3Mo KTsKLSAgICAgICAgYW5pbWF0aW9uKCktPnN1c3BlbmRBbmltYXRpb25zRm9yRG9jdW1lbnQoZG9j dW1lbnQoKSk7Ci0gICAgICAgIGRvY3VtZW50KCktPnN1c3BlbmRBY3RpdmVET01PYmplY3RzKEFj dGl2ZURPTU9iamVjdDo6UGFnZVdpbGxCZVN1c3BlbmRlZCk7CisgICAgaWYgKG1fZG9jICYmIGFj dGl2ZURPTU9iamVjdHNBbmRBbmltYXRpb25zU3VzcGVuZGVkKCkpIHsKKyAgICAgICAgbV9kb2Mt PnN1c3BlbmRTY3JpcHRlZEFuaW1hdGlvbkNvbnRyb2xsZXJDYWxsYmFja3MoKTsKKyAgICAgICAg bV9hbmltYXRpb25Db250cm9sbGVyLnN1c3BlbmRBbmltYXRpb25zRm9yRG9jdW1lbnQobV9kb2Mu Z2V0KCkpOworICAgICAgICBtX2RvYy0+c3VzcGVuZEFjdGl2ZURPTU9iamVjdHMoQWN0aXZlRE9N T2JqZWN0OjpQYWdlV2lsbEJlU3VzcGVuZGVkKTsKICAgICB9CiB9CiAK