157924 2016-05-19 14:34:32 -0700 REGRESSION (r188642): All pages are blank when printing a webpage in iOS Safari 2016-05-21 18:12:38 -0700 1 1 1 Unclassified WebKit Printing Other iPhone / iPad All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=157937 InRadar P1 Blocker --- 148140 1 aestes aestes bfulgham commit-queue darin dbates ddkilzer fpizlo ggaren thorton webkit-bug-importer oldest_to_newest 1194965 0 aestes 2016-05-19 14:34:32 -0700 When UIPrintInteractionController asks WKWebView to print a webpage, it does so in several phases. First we're asked to compute the page count, then later we're asked to draw each page into a supplied CGContext in a series of messages. When WKWebView is asked for the page count, we send a message to the Web process asking it to compute and return the page count synchronously and then immediately start drawing the page for printing. If the drawing has finished by the time we're asked to print the first page, then we can do so without waiting. But if it hasn't then we block by calling Connection::waitForMessage(), passing std::chromo::milliseconds::max() as the relative timeout. Prior to r188642, Connection::waitForMessage() called std::condition_variable::wait_for(), which takes a relative timeout value. r188642 replaced this with WTF::Condition::waitUntil(), which takes an absolute timeout instead. To convert from relative to absolute, this line was added to Connection::waitForMessage(): Condition::Clock::time_point absoluteTimeout = Condition::Clock::now() + timeout; Condition::Clock::now() has a duration in nanoseconds, which causes signed overflow when converted to milliseconds and added to milliseconds::max(). This makes absoluteTimeout end up being less than Condition::Clock::now(), and so instead of waiting indefinitely for the printed data, we timeout immediately and print nothing. 1194971 1 aestes 2016-05-19 14:38:45 -0700 rdar://problem/22524550 1194972 2 fpizlo 2016-05-19 14:39:09 -0700 Ouch! 1194977 3 ggaren 2016-05-19 14:43:24 -0700 I think the right solution here is probably to change the "+" to an add with clamping to max on overflow. One way to do that: If (absoluteTimeout < timeout) absoluteTimeout = Condition::Clock::time_point::max(); 1194982 4 fpizlo 2016-05-19 14:52:09 -0700 There are two issues I think: 1) The functional style would have you let WTF::Condition do the time math for you. Instead of having a wait loop, do: m_condition.waitFor(m_lock, timeout, [&] () -> bool { loop body }); 2) The style that I've been settling on is to just use doubles for time. Maybe when I have time to mess around I'll propose that we do this. I've encountered so many bugs due to std::chrono having overflows where our old double-based time code would have recovered like a champ. In fact, one of those overflows was in GCC's version of libstdc++! It would cause some uses of std::condition_variable to freak out on Linux but not anywhere else. In this case, we could just go back to using a double timeout. waitForSeconds(+Inf) should correctly cause our code to recognize that you want to timeout forever. I'm also fine with Geoff's proposed solution. 1195022 5 aestes 2016-05-19 16:25:51 -0700 (In reply to comment #4) > There are two issues I think: > > 1) The functional style would have you let WTF::Condition do the time math > for you. Instead of having a wait loop, do: > > m_condition.waitFor(m_lock, timeout, [&] () -> bool { loop body }); Unfortunately this would just move the overflow into Condition::absoluteFromRelative(), where have these two lines: Clock::duration myRelativeTimeout = std::chrono::duration_cast<Clock::duration>(relativeTimeout); return Clock::now() + myRelativeTimeout; libc++ represents both nanoseconds and milliseconds using the same type (long long), so the duration_cast will overflow trying to convert the largest long long into an even larger number of nanosecond ticks. Now we're right back where we started, subtracting from Clock::now() instead of adding. > > 2) The style that I've been settling on is to just use doubles for time. > Maybe when I have time to mess around I'll propose that we do this. I've > encountered so many bugs due to std::chrono having overflows where our old > double-based time code would have recovered like a champ. In fact, one of > those overflows was in GCC's version of libstdc++! It would cause some uses > of std::condition_variable to freak out on Linux but not anywhere else. > > In this case, we could just go back to using a double timeout. > waitForSeconds(+Inf) should correctly cause our code to recognize that you > want to timeout forever. > > I'm also fine with Geoff's proposed solution. Yeah, this is basically what I proposed doing in Radar, although now Geoff made me realize that my patch has a totally unnecessary subtraction in it! Thanks for the feedback, Geoff and Phil. 1195023 6 fpizlo 2016-05-19 16:26:52 -0700 (In reply to comment #5) > (In reply to comment #4) > > There are two issues I think: > > > > 1) The functional style would have you let WTF::Condition do the time math > > for you. Instead of having a wait loop, do: > > > > m_condition.waitFor(m_lock, timeout, [&] () -> bool { loop body }); > > Unfortunately this would just move the overflow into > Condition::absoluteFromRelative(), where have these two lines: > > Clock::duration myRelativeTimeout = > std::chrono::duration_cast<Clock::duration>(relativeTimeout); > > return Clock::now() + myRelativeTimeout; > > libc++ represents both nanoseconds and milliseconds using the same type > (long long), so the duration_cast will overflow trying to convert the > largest long long into an even larger number of nanosecond ticks. Now we're > right back where we started, subtracting from Clock::now() instead of adding. Can you file a bug about that? :-) > > > > > 2) The style that I've been settling on is to just use doubles for time. > > Maybe when I have time to mess around I'll propose that we do this. I've > > encountered so many bugs due to std::chrono having overflows where our old > > double-based time code would have recovered like a champ. In fact, one of > > those overflows was in GCC's version of libstdc++! It would cause some uses > > of std::condition_variable to freak out on Linux but not anywhere else. > > > > In this case, we could just go back to using a double timeout. > > waitForSeconds(+Inf) should correctly cause our code to recognize that you > > want to timeout forever. > > > > I'm also fine with Geoff's proposed solution. > > Yeah, this is basically what I proposed doing in Radar, although now Geoff > made me realize that my patch has a totally unnecessary subtraction in it! > > Thanks for the feedback, Geoff and Phil. 1195062 7 aestes 2016-05-19 17:56:03 -0700 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > There are two issues I think: > > > > > > 1) The functional style would have you let WTF::Condition do the time math > > > for you. Instead of having a wait loop, do: > > > > > > m_condition.waitFor(m_lock, timeout, [&] () -> bool { loop body }); > > > > Unfortunately this would just move the overflow into > > Condition::absoluteFromRelative(), where have these two lines: > > > > Clock::duration myRelativeTimeout = > > std::chrono::duration_cast<Clock::duration>(relativeTimeout); > > > > return Clock::now() + myRelativeTimeout; > > > > libc++ represents both nanoseconds and milliseconds using the same type > > (long long), so the duration_cast will overflow trying to convert the > > largest long long into an even larger number of nanosecond ticks. Now we're > > right back where we started, subtracting from Clock::now() instead of adding. > > Can you file a bug about that? :-) Sure thing! https://bugs.webkit.org/show_bug.cgi?id=157937 1195117 8 aestes 2016-05-20 03:24:49 -0700 (In reply to comment #3) > I think the right solution here is probably to change the "+" to an add with > clamping to max on overflow. > > One way to do that: > > If (absoluteTimeout < timeout) > absoluteTimeout = Condition::Clock::time_point::max(); Sorry, I spoke too soon. This ends up not working because the operator< for durations converts both operands into a common duration type before making the comparison. In this case the common duration is nanoseconds, which we already know milliseconds::max() will overflow on conversion. What I ended up doing was to compute the amount of time remaining on the clock, convert that duration to milliseconds, then pick the smaller of that value and the timeout for computing absoluteTimeout. The conversion will reduce the maximum possible timeout by up to 1 millisecond, but that seems harmless. 1195118 9 279475 aestes 2016-05-20 03:57:17 -0700 Created attachment 279475 Patch 1195379 10 279475 bfulgham 2016-05-21 16:23:00 -0700 Comment on attachment 279475 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279475&action=review I would approve this patch if I was a WK2 owner. r=me, though this carries no weight. :-) > Source/WebKit2/ChangeLog:5 > + rdar://problem/22524550 This should be <rdar://problem/22524550> > Source/WebKit2/Platform/IPC/Connection.cpp:438 > + auto absoluteTimeout = now + std::min(remainingClockTime, timeout); Given how likely we are to make this mistake again, I wonder if we could create a Condition::Clock method, something like Condition::Clock::absoluteTimeout(timeout) or something, then police (in a separate patch) places where this type of calculation is needed. > Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:-4557 > - It's funny that we had this calculation. Did std::chromo::milliseconds::max() not exist in earlier clang or something? 1195380 11 279475 commit-queue 2016-05-21 16:51:34 -0700 Comment on attachment 279475 Patch Clearing flags on attachment: 279475 Committed r201246: <http://trac.webkit.org/changeset/201246> 1195381 12 commit-queue 2016-05-21 16:51:38 -0700 All reviewed patches have been landed. Closing bug. 1195384 13 aestes 2016-05-21 17:45:03 -0700 (In reply to comment #10) > Comment on attachment 279475 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=279475&action=review > > I would approve this patch if I was a WK2 owner. r=me, though this carries > no weight. :-) > > > Source/WebKit2/ChangeLog:5 > > + rdar://problem/22524550 > > This should be <rdar://problem/22524550> I let the commit queue land my patch without changing this. Is there a reason we need to add the brackets? Do some of our tools expect them? > > > Source/WebKit2/Platform/IPC/Connection.cpp:438 > > + auto absoluteTimeout = now + std::min(remainingClockTime, timeout); > > Given how likely we are to make this mistake again, I wonder if we could > create a Condition::Clock method, something like > Condition::Clock::absoluteTimeout(timeout) or something, then police (in a > separate patch) places where this type of calculation is needed. That would be a good idea, but I wanted to keep this patch constrained to the issue at hand. Condition::Clock already has a relativeToAbsolute() function, and https://bugs.webkit.org/show_bug.cgi?id=157937 is for fixing a similar bug in it. It sounds like Phil might want to make even more sweeping changes, like using doubles instead of std::chrono, so I'll leave the discussion of how to systematically prevent these issues occur there. > > > Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:-4557 > > - > > It's funny that we had this calculation. Did > std::chromo::milliseconds::max() not exist in earlier clang or something? No, that was a previous fix to this issue back when we were using std::condition_variable. We encountered the same milliseconds->nanoseconds overflow bug back then, we just didn't have the overflow-on-addition issue since std::condition_variable took a relative timeout. 1195386 14 bfulgham 2016-05-21 18:12:38 -0700 (In reply to comment #13) > > > Source/WebKit2/ChangeLog:5 > > > + rdar://problem/22524550 > > > > This should be <rdar://problem/22524550> > > I let the commit queue land my patch without changing this. Is there a > reason we need to add the brackets? Do some of our tools expect them? I know that is the form our tools produce. I think this style was created because that was how copy/paste from Radar used to format it. At any rate, no need to change this. > function, and https://bugs.webkit.org/show_bug.cgi?id=157937 is for fixing a > similar bug in it. It sounds like Phil might want to make even more sweeping > changes, like using doubles instead of std::chrono, so I'll leave the > discussion of how to systematically prevent these issues occur there. Sounds good! 279475 2016-05-20 03:57:17 -0700 2016-05-21 16:51:34 -0700 Patch bug-157924-20160520035818.patch text/plain 5133 aestes U3VidmVyc2lvbiBSZXZpc2lvbjogMjAxMjAxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggM2UxZmFjMDUwMjZhN2Jm OWYyYmMwODA1YzY2MTNiZjljN2UzYTdhOS4uZmJiOTBhMTNjYjFkYWRjNjNkYWVkY2Q0YzI5MjNm MTRmNTM4ZWI2MSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDM5IEBACisyMDE2LTA1LTIwICBBbmR5 IEVzdGVzICA8YWVzdGVzQGFwcGxlLmNvbT4KKworICAgICAgICBSRUdSRVNTSU9OIChyMTg4NjQy KTogQWxsIHBhZ2VzIGFyZSBibGFuayB3aGVuIHByaW50aW5nIGEgd2VicGFnZSBpbiBpT1MgU2Fm YXJpCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNTc5 MjQKKyAgICAgICAgcmRhcjovL3Byb2JsZW0vMjI1MjQ1NTAKKworICAgICAgICBSZXZpZXdlZCBi eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBXaGVuIFVJUHJpbnRJbnRlcmFjdGlvbkNvbnRy b2xsZXIgYXNrcyBXS1dlYlZpZXcgdG8gcHJpbnQgYSB3ZWJwYWdlLCBpdCBkb2VzIHNvIGluIHNl dmVyYWwgcGhhc2VzLiBGaXJzdCB3ZSdyZQorICAgICAgICBhc2tlZCB0byBjb21wdXRlIHRoZSBw YWdlIGNvdW50LCBmb2xsb3dlZCBsYXRlciBieSBhIHNlcmllcyBvZiBtZXNzYWdlcyBhc2tpbmcg dXMgdG8gZHJhdyBlYWNoIHBhZ2UgaW50byBhCisgICAgICAgIHByb3ZpZGVkIENHQ29udGV4dC4K KworICAgICAgICBXaGVuIGFza2VkIGZvciB0aGUgcGFnZSBjb3VudCwgd2Ugc2VuZCBhIG1lc3Nh Z2UgdG8gdGhlIFdlYiBwcm9jZXNzIGluc3RydWN0aW5nIGl0IHRvIGNvbXB1dGUgYW5kCisgICAg ICAgIHJldHVybiB0aGUgcGFnZSBjb3VudCBzeW5jaHJvbm91c2x5IGFuZCB0aGVuIGltbWVkaWF0 ZWx5IHN0YXJ0IGRyYXdpbmcgdGhlIHBhZ2UgZm9yIHByaW50aW5nLiBJZiB0aGUgZHJhd2luZyBo YXMKKyAgICAgICAgZmluaXNoZWQgYnkgdGhlIHRpbWUgd2UncmUgYXNrZWQgdG8gcHJpbnQgdGhl IGZpcnN0IHBhZ2UsIHRoZW4gd2UgY2FuIGRvIHNvIHdpdGhvdXQgd2FpdGluZy4gQnV0IGlmIGl0 IGhhc24ndAorICAgICAgICB0aGVuIHdlIGJsb2NrIGJ5IGNhbGxpbmcgQ29ubmVjdGlvbjo6d2Fp dEZvck1lc3NhZ2UoKSwgcGFzc2luZyBzdGQ6OmNocm9tbzo6bWlsbGlzZWNvbmRzOjptYXgoKSBh cyB0aGUgcmVsYXRpdmUKKyAgICAgICAgdGltZW91dC4KKyAgICAgICAgCisgICAgICAgIFByaW9y IHRvIHIxODg2NDIsIENvbm5lY3Rpb246OndhaXRGb3JNZXNzYWdlKCkgY2FsbGVkIHN0ZDo6Y29u ZGl0aW9uX3ZhcmlhYmxlOjp3YWl0X2ZvcigpLCB3aGljaCB0YWtlcyBhCisgICAgICAgIHJlbGF0 aXZlIHRpbWVvdXQgdmFsdWUuIHIxODg2NDIgcmVwbGFjZWQgdGhpcyB3aXRoIFdURjo6Q29uZGl0 aW9uOjp3YWl0VW50aWwoKSwgd2hpY2ggdGFrZXMgYW4gYWJzb2x1dGUgdGltZW91dAorICAgICAg ICBpbnN0ZWFkLiBUbyBjb252ZXJ0IGZyb20gcmVsYXRpdmUgdG8gYWJzb2x1dGUsIHRoaXMgbGlu ZSB3YXMgYWRkZWQgdG8gQ29ubmVjdGlvbjo6d2FpdEZvck1lc3NhZ2UoKToKKworICAgICAgICAg ICAgQ29uZGl0aW9uOjpDbG9jazo6dGltZV9wb2ludCBhYnNvbHV0ZVRpbWVvdXQgPSBDb25kaXRp b246OkNsb2NrOjpub3coKSArIHRpbWVvdXQ7CisKKyAgICAgICAgc3RkOjpjaHJvbm8gd2lsbCBj b252ZXJ0IGJvdGggb3BlcmFuZHMgdG8gYSBjb21tb24gZHVyYXRpb24gdHlwZSBiZWZvcmUgcGVy Zm9ybWluZyB0aGUgYWRkaXRpb24uIFdoZW4gdGltZW91dAorICAgICAgICBlcXVhbHMgc29tZXRo aW5nIHZlcnkgbGFyZ2UsIGxpa2UgbWlsbGlzZWNvbmRzOjptYXgoKSwgdGhpcyBjb252ZXJzaW9u IHJlc3VsdHMgaW4gc2lnbmVkIGludGVnZXIgb3ZlcmZsb3csCisgICAgICAgIGdpdmluZyBhYnNv bHV0ZVRpbWVvdXQgYSB2YWx1ZSBsZXNzIHRoYW4gQ2xvY2s6Om5vdygpIGFuZCBtYWtpbmcgd2Fp dEZvck1lc3NhZ2UgdGltZSBvdXQgaW1tZWRpYXRlbHkuCisgICAgICAgIAorICAgICAgICBUbyBm aXggdGhpcywgY29tcHV0ZSBob3cgbWFueSBtaWxsaXNlY29uZHMgcmVtYWluIG9uIG91ciBjbG9j aywgYW5kIGFkZCB0aGUgc21hbGxlciBvZiB0aGF0IGFuZCB0aGUgdGltZW91dAorICAgICAgICB2 YWx1ZSB0byBDbG9jazo6bm93KCkgdG8gYXJyaXZlIGF0IGFuIGFic29sdXRlIHRpbWVvdXQuCisK KyAgICAgICAgKiBQbGF0Zm9ybS9JUEMvQ29ubmVjdGlvbi5jcHA6CisgICAgICAgIChJUEM6OkNv bm5lY3Rpb246OndhaXRGb3JNZXNzYWdlKToKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL0NvY29h L1dLV2ViVmlldy5tbToKKyAgICAgICAgKC1bV0tXZWJWaWV3IF9wcmludGVkRG9jdW1lbnRdKTog UmVtb3ZlZCBhbiB1bm5lY2Vzc2FyeSBuYW5vc2Vjb25kcy10by1taWxsaXNlY29uZHMgY29udmVy c2lvbi4KKwogMjAxNi0wNS0xNiAgRW5yaWNhIENhc3VjY2kgIDxlbnJpY2FAYXBwbGUuY29tPgog CiAgICAgICAgIE5vIGNhbmRpZGF0ZSBwdW5jdHVhdGlvbiB3aGVuIHR5cGluZyBwdW5jdHVhdGlv biBpbiBXSzIgdGV4dCBmaWVsZC4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1BsYXRmb3Jt L0lQQy9Db25uZWN0aW9uLmNwcCBiL1NvdXJjZS9XZWJLaXQyL1BsYXRmb3JtL0lQQy9Db25uZWN0 aW9uLmNwcAppbmRleCA0OTQ5OGQyZTUyNjMzN2Q2OGEzZTdmNjVjZGRmODBiYzdhMTA0Mjg0Li4y MDAwMDliYTAyNmNlNWFmODhjOTA0MGJhOTg0YTQzNWM0NzcwNTNjIDEwMDY0NAotLS0gYS9Tb3Vy Y2UvV2ViS2l0Mi9QbGF0Zm9ybS9JUEMvQ29ubmVjdGlvbi5jcHAKKysrIGIvU291cmNlL1dlYktp dDIvUGxhdGZvcm0vSVBDL0Nvbm5lY3Rpb24uY3BwCkBAIC00MzIsOCArNDMyLDEyIEBAIHN0ZDo6 dW5pcXVlX3B0cjxNZXNzYWdlRGVjb2Rlcj4gQ29ubmVjdGlvbjo6d2FpdEZvck1lc3NhZ2UoU3Ry aW5nUmVmZXJlbmNlIG1lc3NhCiAgICAgICAgIG1fd2FpdGluZ0Zvck1lc3NhZ2UgPSAmd2FpdGlu Z0Zvck1lc3NhZ2U7CiAgICAgfQogCisgICAgLy8gQ2xhbXAgdGhlIHRpbWVvdXQgdG8gaG93ZXZl ciBtdWNoIHRpbWUgaXMgcmVtYWluaW5nIG9uIG91ciBjbG9jay4KKyAgICBhdXRvIG5vdyA9IENv bmRpdGlvbjo6Q2xvY2s6Om5vdygpOworICAgIGF1dG8gcmVtYWluaW5nQ2xvY2tUaW1lID0gc3Rk OjpjaHJvbm86OmR1cmF0aW9uX2Nhc3Q8c3RkOjpjaHJvbm86Om1pbGxpc2Vjb25kcz4oQ29uZGl0 aW9uOjpDbG9jazo6dGltZV9wb2ludDo6bWF4KCkgLSBub3cpOworICAgIGF1dG8gYWJzb2x1dGVU aW1lb3V0ID0gbm93ICsgc3RkOjptaW4ocmVtYWluaW5nQ2xvY2tUaW1lLCB0aW1lb3V0KTsKKwog ICAgIC8vIE5vdyB3YWl0IGZvciBpdCB0byBiZSBzZXQuCi0gICAgQ29uZGl0aW9uOjpDbG9jazo6 dGltZV9wb2ludCBhYnNvbHV0ZVRpbWVvdXQgPSBDb25kaXRpb246OkNsb2NrOjpub3coKSArIHRp bWVvdXQ7CiAgICAgd2hpbGUgKHRydWUpIHsKICAgICAgICAgc3RkOjp1bmlxdWVfbG9jazxMb2Nr PiBsb2NrKG1fd2FpdEZvck1lc3NhZ2VNdXRleCk7CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJL aXQyL1VJUHJvY2Vzcy9BUEkvQ29jb2EvV0tXZWJWaWV3Lm1tIGIvU291cmNlL1dlYktpdDIvVUlQ cm9jZXNzL0FQSS9Db2NvYS9XS1dlYlZpZXcubW0KaW5kZXggNDM0ODRiNWZkOWIzOTU4YzEyMjll ZjJmMjdhYWVmMWRlOGE1MGRjYi4uZjBkYTkwNThlYTAwNWFhZjBiYWRjMDg2NWM0YmIxY2NkYzI4 NGEwNiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9Db2NvYS9XS1dl YlZpZXcubW0KKysrIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9Db2NvYS9XS1dlYlZp ZXcubW0KQEAgLTQ1NTAsMTEgKzQ1NTAsNiBAQCAtICh2b2lkKV9lbmRQcmludGluZwogICAgIF9w YWdlLT5zZW5kKE1lc3NhZ2VzOjpXZWJQYWdlOjpFbmRQcmludGluZygpKTsKIH0KIAotLy8gRklY TUU6IG1pbGxpc2Vjb25kczo6bWF4KCkgb3ZlcmZsb3dzIHdoZW4gY29udmVydGVkIHRvIG5hbm9z ZWNvbmRzLCBjYXVzaW5nIGNvbmRpdGlvbl92YXJpYWJsZTo6d2FpdF9mb3IoKSB0byBiZWxpZXZl Ci0vLyBhIHRpbWVvdXQgb2NjdXJyZWQgb24gYW55IHNwdXJpb3VzIHdha2V1cC4gVXNlIG5hbm9z ZWNvbmRzOjptYXgoKSAoY29udmVydGVkIHRvIG1zKSB0byBhdm9pZCB0aGlzLiBXZSBzaG91bGQg cGVyaGFwcwotLy8gY2hhbmdlIHdhaXRGb3JBbmREaXNwYXRjaEltbWVkaWF0ZWx5KCkgdG8gdGFr ZSBuYW5vc2Vjb25kcyB0byBhdm9pZCB0aGlzIGlzc3VlLgotc3RhdGljIGNvbnN0ZXhwciBzdGQ6 OmNocm9ubzo6bWlsbGlzZWNvbmRzIGRpZEZpbmlzaExvYWRpbmdUaW1lb3V0ID0gc3RkOjpjaHJv bm86OmR1cmF0aW9uX2Nhc3Q8c3RkOjpjaHJvbm86Om1pbGxpc2Vjb25kcz4oc3RkOjpjaHJvbm86 Om5hbm9zZWNvbmRzOjptYXgoKSk7Ci0KIC0gKENHUERGRG9jdW1lbnRSZWYpX3ByaW50ZWREb2N1 bWVudAogewogICAgIGlmIChbc2VsZiBfaXNEaXNwbGF5aW5nUERGXSkgewpAQCAtNDU2Myw3ICs0 NTU4LDcgQEAgLSAoQ0dQREZEb2N1bWVudFJlZilfcHJpbnRlZERvY3VtZW50CiAgICAgfQogCiAg ICAgaWYgKF9wYWdlSXNQcmludGluZ1RvUERGKSB7Ci0gICAgICAgIGlmICghX3BhZ2UtPnByb2Nl c3MoKS5jb25uZWN0aW9uKCktPndhaXRGb3JBbmREaXNwYXRjaEltbWVkaWF0ZWx5PE1lc3NhZ2Vz OjpXZWJQYWdlUHJveHk6OkRpZEZpbmlzaERyYXdpbmdQYWdlc1RvUERGPihfcGFnZS0+cGFnZUlE KCksIGRpZEZpbmlzaExvYWRpbmdUaW1lb3V0KSkgeworICAgICAgICBpZiAoIV9wYWdlLT5wcm9j ZXNzKCkuY29ubmVjdGlvbigpLT53YWl0Rm9yQW5kRGlzcGF0Y2hJbW1lZGlhdGVseTxNZXNzYWdl czo6V2ViUGFnZVByb3h5OjpEaWRGaW5pc2hEcmF3aW5nUGFnZXNUb1BERj4oX3BhZ2UtPnBhZ2VJ RCgpLCBzdGQ6OmNocm9ubzo6bWlsbGlzZWNvbmRzOjptYXgoKSkpIHsKICAgICAgICAgICAgIEFT U0VSVF9OT1RfUkVBQ0hFRCgpOwogICAgICAgICAgICAgcmV0dXJuIG51bGxwdHI7CiAgICAgICAg IH0K