90469 2012-07-03 10:13:11 -0700 storage tests are flaky (crashing) on windows 2013-01-30 12:58:11 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 90517 91133 91275 91403 91421 91637 91672 1 eae wez abarth alecflett dgrogan haraken hayato japhet jochen jsbell rafaelw webkit.review.bot wez oldest_to_newest 662322 0 eae 2012-07-03 10:13:11 -0700 storage/indexeddb/mozilla/indexes.html storage/indexeddb/mozilla/key-requirements-inline-and-passed.html storage/websql/multiple-databases-garbage-collection.html 662353 1 jsbell 2012-07-03 10:39:47 -0700 Huh, more than just those - flakiness link: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=storage%2Findexeddb%2F This is recent... something just prior to r121610. 662359 2 jsbell 2012-07-03 10:47:47 -0700 Partial stack from a debug builder: crash log for DumpRenderTree (pid 13452): STDOUT: <empty> STDERR: Backtrace: STDERR: WebKit::WebFilterOperations::at [0x114A432F+10164239] STDERR: WebKit::WebFilterOperations::at [0x114A440F+10164463] STDERR: WebKit::WebFilterOperations::at [0x119EE2C1+15710113] STDERR: v8::Locker::StopPreemption [0x01771EFC+420348] ... STDERR: v8::Locker::StopPreemption [0x018E48EF+1938415] STDERR: (No symbol) [0x0570A336] ... STDERR: (No symbol) [0x05712B4A] STDERR: v8::Locker::StopPreemption [0x0176B48C+393100] STDERR: v8::Locker::StopPreemption [0x0176B214+392468] STDERR: v8::Locker::StopPreemption [0x0176EBBD+407229] STDERR: v8::FunctionTemplate::GetFunction [0x016F6A35+357] STDERR: WebKit::WebFilterOperations::at [0x119E091A+15654394] ... STDERR: WebKit::WebFilterOperations::at [0x10B01947+60967] STDERR: v8::Locker::StopPreemption [0x017C240D+749325] ... STDERR: v8::Locker::StopPreemption [0x019E1881+2974593] STDERR: (No symbol) [0x0570A336] ... STDERR: (No symbol) [0x05712B4A] STDERR: v8::Locker::StopPreemption [0x0176B48C+393100] STDERR: v8::Locker::StopPreemption [0x0176B214+392468] STDERR: v8::Script::Run [0x016DF901+593] STDERR: WebKit::WebFilterOperations::at [0x1148FD06+10080742] ... STDERR: WebKit::WebFilterOperations::at [0x1191FFC7+14865575] STDERR: std::_Init_locks::operator= [0x1225C3B0+2330128] STDERR: webkit::npapi::PluginList::DebugPluginLoading [0x03E1FB30+721199] STDERR: (No symbol) [0x0058D6A9] ... STDERR: (No symbol) [0x005942EC] STDERR: base::DelegateSimpleThreadPool::~DelegateSimpleThreadPool [0x0094518F+418550] STDERR: base::DelegateSimpleThreadPool::~DelegateSimpleThreadPool [0x0094BB39+445600] This stack pattern (crash in WebKit::WebFilterOperations::at coming from base::DelegateSimpleThreadPool destructor) is consistent among these crashes. 662364 3 jsbell 2012-07-03 10:52:38 -0700 Those stacks make no sense, though; something funky must be going on. 662369 4 jsbell 2012-07-03 10:57:26 -0700 The storage/websql test has a similar stack: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=storage%2Fwebsql%2Fmultiple-databases-garbage-collection.html There's basically no code in common between websql and indexeddb, so I don't think this is related to changed in either of those modules. 662371 5 jsbell 2012-07-03 11:01:14 -0700 Look at the win dbg stack in http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=fast%2Fjs%2Finteger-division-neg2tothe32-by-neg1.html - same thing. W...T...F... 662377 6 eae 2012-07-03 11:05:05 -0700 abarth, could this possibly be from the new bot set up? 662382 7 jsbell 2012-07-03 11:09:28 -0700 Given that the crashes do seem to be module specific (if you ignore the stacks) and a fairly frequent consistency per-test, I'm guessing something is awry in the backtrace generation. So likely real IDB crashes, but the stack symbols are useless. 662383 8 jsbell 2012-07-03 11:10:04 -0700 (In reply to comment #7) > Given that the crashes do seem to be module specific (if you ignore the stacks) and a fairly frequent consistency per-test, I'm guessing something is awry in the backtrace generation. So likely real IDB crashes, but the stack symbols are useless. Trying in English: "and the frequency is consistent per test" 662411 9 abarth 2012-07-03 11:48:59 -0700 (In reply to comment #6) > abarth, could this possibly be from the new bot set up? The new bot setup is only for the cr-linux-ews bots, not any of the buildbots. 662460 10 jsbell 2012-07-03 13:46:42 -0700 The crashes seem to start around r121610. http://trac.webkit.org/log/?verbose=on&rev=121612&stop_rev=121600 shows changes around that range. r121612 (an IDB change) would be an obvious candidate except there are crashes that occur before that change and it's pretty innocuous. (Many of the IDB crashes are in tests that don't go anywhere near cursors, either.) http://trac.webkit.org/changeset/121610/ itself catches my eye as it is the earliest revision in all the crash blame ranges. It changes the NPAPI behavior in the ScriptController and webkit::npapi::PluginList::DebugPluginLoading on the stack is still catching my eye. Is there any chance it's running and tickling an underlying issue in the WebSQL and IndexedDB code because they are async tests that have objects that outlive the test itself? 662468 11 wez 2012-07-03 14:04:23 -0700 (In reply to comment #10) > The crashes seem to start around r121610. http://trac.webkit.org/log/?verbose=on&rev=121612&stop_rev=121600 shows changes around that range. r121612 (an IDB change) would be an obvious candidate except there are crashes that occur before that change and it's pretty innocuous. (Many of the IDB crashes are in tests that don't go anywhere near cursors, either.) > > http://trac.webkit.org/changeset/121610/ itself catches my eye as it is the earliest revision in all the crash blame ranges. It changes the NPAPI behavior in the ScriptController and webkit::npapi::PluginList::DebugPluginLoading on the stack is still catching my eye. Is there any chance it's running and tickling an underlying issue in the WebSQL and IndexedDB code because they are async tests that have objects that outlive the test itself? r121610 changes the way in which the window scriptable object is protected from being leaked by badly-behaved plugins - the NPObject passed to the plugin has its reference to the underlying V8 object Dispose()d, and ignores all subsequent attempts at scripting. From the calling plugin's point of view the behaviour should be no different from the previous NPObjectWrapper behaviour - scripting the object should simply stop working once teardown reaches a clearScriptObjects, so if the CL causes crashes then I think I must have missed a check of the underlying V8 object's validity somewhere. 665220 12 jsbell 2012-07-09 15:18:31 -0700 *** Bug 90754 has been marked as a duplicate of this bug. *** 665223 13 jsbell 2012-07-09 15:18:40 -0700 *** Bug 90743 has been marked as a duplicate of this bug. *** 665868 14 rafaelw 2012-07-10 10:35:04 -0700 Added another flaky test to TestExpectations in r122235 (storage/indexeddb/cursor-added-bug.html) 666810 15 151717 wez 2012-07-11 09:47:10 -0700 Created attachment 151717 Patch 667541 16 151717 haraken 2012-07-12 02:06:55 -0700 Comment on attachment 151717 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=151717&action=review > Source/WebCore/ChangeLog:10 > + This patch is intended to resolve flakiness in the storage tests identified in the bug. Would you list up the flaky tests here? > Source/WebCore/bindings/v8/NPV8Object.cpp:189 > + v8NpObject->rootObject = 0; This line is not related to fixing the flakiness, right? (This line is fine. I just want to confirm my understanding.) 667976 17 151998 wez 2012-07-12 10:53:17 -0700 Created attachment 151998 Patch 667983 18 wez 2012-07-12 10:56:33 -0700 (In reply to comment #16) > (From update of attachment 151717 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=151717&action=review > > > Source/WebCore/ChangeLog:10 > > + This patch is intended to resolve flakiness in the storage tests identified in the bug. > > Would you list up the flaky tests here? I've copied the list from Emil's original description to the ChangeLog. > > Source/WebCore/bindings/v8/NPV8Object.cpp:189 > > + v8NpObject->rootObject = 0; > > This line is not related to fixing the flakiness, right? (This line is fine. I just want to confirm my understanding.) Yes, this is to make sure that if we're failing to correctly check validity prior to rootObject accesses then we'll fail with a NULL dereference. 667986 19 151998 haraken 2012-07-12 10:57:53 -0700 Comment on attachment 151998 Patch Thanks for the clarification. Looks OK. 668002 20 151998 haraken 2012-07-12 11:08:50 -0700 Comment on attachment 151998 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=151998&action=review > Source/WebCore/ChangeLog:8 > + Add a missing check that the underlying V8 object reference in a V8 NPObject is valid, and zero the NPObject's rootObject member when disposing it, to ensure that it won't be mistakenly touched after that point. Nit: Next time you write a ChangeLog, please wrap such long lines. 668026 21 151998 webkit.review.bot 2012-07-12 11:31:24 -0700 Comment on attachment 151998 Patch Clearing flags on attachment: 151998 Committed r122488: <http://trac.webkit.org/changeset/122488> 668027 22 webkit.review.bot 2012-07-12 11:31:29 -0700 All reviewed patches have been landed. Closing bug. 668029 23 jsbell 2012-07-12 11:32:49 -0700 Thanks, wez@ - I'll keep an eye on the storage/ tests and report back here on the status of the flakiness. If it goes away I'll remove the TextExpectations lines. 668260 24 jsbell 2012-07-12 14:49:29 -0700 Initial signs show the crashiness is still there, but it will take a while for usable stacks to come in on the debug bots. 674751 25 jsbell 2012-07-20 11:09:07 -0700 For posterity, as various things point back to this bug: In http://trac.webkit.org/changeset/123110 we rolled back http://trac.webkit.org/changeset/121610 and http://trac.webkit.org/changeset/122488. This resolved the flakiness seen in this and duplicate/dependent bugs. 674771 26 haraken 2012-07-20 11:14:53 -0700 (In reply to comment #25) > For posterity, as various things point back to this bug: > > In http://trac.webkit.org/changeset/123110 we rolled back http://trac.webkit.org/changeset/121610 and http://trac.webkit.org/changeset/122488. This resolved the flakiness seen in this and duplicate/dependent bugs. Maybe the line 'v8NpObject->rootObject = 0' was the culprit? We inserted the line "just in case". I think that the v8NpObject->v8Object.IsEmpty() check was a correct fix. 674772 27 haraken 2012-07-20 11:15:27 -0700 The patch is reverted. Reopening the bug. 674798 28 wez 2012-07-20 11:39:38 -0700 (In reply to comment #26) > (In reply to comment #25) > > For posterity, as various things point back to this bug: > > > > In http://trac.webkit.org/changeset/123110 we rolled back http://trac.webkit.org/changeset/121610 and http://trac.webkit.org/changeset/122488. This resolved the flakiness seen in this and duplicate/dependent bugs. > > Maybe the line 'v8NpObject->rootObject = 0' was the culprit? We inserted the line "just in case". I think that the v8NpObject->v8Object.IsEmpty() check was a correct fix. That seems unlikely; we specifically added that to ensure that unexpected access to rootObject after Dispose'ing the V8Object reference would trigger well-formed crashes, whereas the flakes look to have trashed stacks. 820447 29 jsbell 2013-01-30 12:58:11 -0800 I don't think this issue as written has anything actionable about it. Future work on npapi plugin cleanup will take place in another bug and the tests this bug talks about are no longer failing (since the triggering change was reverted). Closing this for now. 151717 2012-07-11 09:47:10 -0700 2012-07-12 10:53:12 -0700 Patch bug-90469-20120711094709.patch text/plain 2092 wez U3VidmVyc2lvbiBSZXZpc2lvbjogMTIyMjQwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNDczYTE3Yjk3OWRjNzIy ZDZmYjk2YzlhMzYwNWEzZWU0N2Y5YTNmYy4uMWM4MzIzMmEzYjRhYzg0YzAyZDU5MjFlZDA2NTdj NDJiMDMwMjRlMyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIwIEBACisyMDEyLTA3LTExICBKYW1l cyBXZWF0aGVyYWxsICA8d2V6QGNocm9taXVtLm9yZz4KKworICAgICAgICBzdG9yYWdlIHRlc3Rz IGFyZSBmbGFreSAoY3Jhc2hpbmcpIG9uIHdpbmRvd3MKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTkwNDY5CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkIGEgbWlzc2luZyBjaGVjayB0aGF0IHRoZSB1bmRl cmx5aW5nIFY4IG9iamVjdCByZWZlcmVuY2UgaW4gYSBWOCBOUE9iamVjdCBpcyB2YWxpZCwgYW5k IHplcm8gdGhlIE5QT2JqZWN0J3Mgcm9vdE9iamVjdCBtZW1iZXIgd2hlbiBkaXNwb3NpbmcgaXQs IHRvIGVuc3VyZSB0aGF0IGl0IHdvbid0IGJlIG1pc3Rha2VubHkgdG91Y2hlZCBhZnRlciB0aGF0 IHBvaW50LgorCisgICAgICAgIFRoaXMgcGF0Y2ggaXMgaW50ZW5kZWQgdG8gcmVzb2x2ZSBmbGFr aW5lc3MgaW4gdGhlIHN0b3JhZ2UgdGVzdHMgaWRlbnRpZmllZCBpbiB0aGUgYnVnLgorCisgICAg ICAgICogYmluZGluZ3MvdjgvTlBWOE9iamVjdC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpkaXNw b3NlVW5kZXJseWluZ1Y4T2JqZWN0KToKKyAgICAgICAgWmVybyB0aGUgTlBPYmplY3QncyB1bmRl cmx5aW5nIHJvb3RPYmplY3QuCisgICAgICAgIChfTlBOX0V2YWx1YXRlSGVscGVyKToKKyAgICAg ICAgQWRkIGNoZWNrIHRoYXQgdGhlIHVuZGVybHlpbmcgVjggb2JqZWN0IHJlZmVyZW5jZSBpcyB2 YWxpZC4KKwogMjAxMi0wNy0xMCAgU3VkYXJzYW5hIE5hZ2luZW5pICA8c3VkYXJzYW5hLm5hZ2lu ZW5pQGxpbnV4LmludGVsLmNvbT4KIAogICAgICAgICBbR1RLXSBGaXggbWVtb3J5IGxlYWtzIGJ5 IGFkb3B0aW5nIGFsbG9jYXRpb24gb2YgR2RrUGl4YnVmCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2Vi Q29yZS9iaW5kaW5ncy92OC9OUFY4T2JqZWN0LmNwcCBiL1NvdXJjZS9XZWJDb3JlL2JpbmRpbmdz L3Y4L05QVjhPYmplY3QuY3BwCmluZGV4IGQ0ZDZjZmM5YzI5Yjc1NTU1OTAwYzUyYjQ1ZDEyYmRi M2FhYzdhODguLjZhNzZiZmZmNWZmOTEzY2EyODkzOWMxYmRlNTlmNDg1YWM0NGNiYjcgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL3Y4L05QVjhPYmplY3QuY3BwCisrKyBiL1Nv dXJjZS9XZWJDb3JlL2JpbmRpbmdzL3Y4L05QVjhPYmplY3QuY3BwCkBAIC0xODYsNiArMTg2LDcg QEAgdm9pZCBkaXNwb3NlVW5kZXJseWluZ1Y4T2JqZWN0KE5QT2JqZWN0KiBucE9iamVjdCkKICNl bmRpZgogICAgIHY4TnBPYmplY3QtPnY4T2JqZWN0LkRpc3Bvc2UoKTsKICAgICB2OE5wT2JqZWN0 LT52OE9iamVjdC5DbGVhcigpOworICAgIHY4TnBPYmplY3QtPnJvb3RPYmplY3QgPSAwOwogfQog CiB9IC8vIG5hbWVzcGFjZSBXZWJDb3JlCkBAIC0zMjAsNiArMzIxLDkgQEAgYm9vbCBfTlBOX0V2 YWx1YXRlSGVscGVyKE5QUCBucHAsIGJvb2wgcG9wdXBzQWxsb3dlZCwgTlBPYmplY3QqIG5wT2Jq ZWN0LCBOUFN0cmkKIAogICAgIGlmIChucE9iamVjdC0+X2NsYXNzICE9IG5wU2NyaXB0T2JqZWN0 Q2xhc3MpCiAgICAgICAgIHJldHVybiBmYWxzZTsKKyAgICBWOE5QT2JqZWN0KiB2OE5wT2JqZWN0 ID0gcmVpbnRlcnByZXRfY2FzdDxWOE5QT2JqZWN0Kj4obnBPYmplY3QpOworICAgIGlmICh2OE5w T2JqZWN0LT52OE9iamVjdC5Jc0VtcHR5KCkpCisgICAgICAgIHJldHVybiBmYWxzZTsKIAogICAg IHY4OjpIYW5kbGVTY29wZSBoYW5kbGVTY29wZTsKICAgICB2ODo6SGFuZGxlPHY4OjpDb250ZXh0 PiBjb250ZXh0ID0gdG9WOENvbnRleHQobnBwLCBucE9iamVjdCk7Cg== 151998 2012-07-12 10:53:17 -0700 2012-07-12 11:31:23 -0700 Patch bug-90469-20120712105316.patch text/plain 2276 wez U3VidmVyc2lvbiBSZXZpc2lvbjogMTIyMjQwCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNDczYTE3Yjk3OWRjNzIy ZDZmYjk2YzlhMzYwNWEzZWU0N2Y5YTNmYy4uZjU4NWU4ZGY1YjU4ZTA0MmU5N2RmNDM3MjM3MDI2 NTM1MTMwNTIwZiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIzIEBACisyMDEyLTA3LTExICBKYW1l cyBXZWF0aGVyYWxsICA8d2V6QGNocm9taXVtLm9yZz4KKworICAgICAgICBzdG9yYWdlIHRlc3Rz IGFyZSBmbGFreSAoY3Jhc2hpbmcpIG9uIHdpbmRvd3MKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTkwNDY5CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkIGEgbWlzc2luZyBjaGVjayB0aGF0IHRoZSB1bmRl cmx5aW5nIFY4IG9iamVjdCByZWZlcmVuY2UgaW4gYSBWOCBOUE9iamVjdCBpcyB2YWxpZCwgYW5k IHplcm8gdGhlIE5QT2JqZWN0J3Mgcm9vdE9iamVjdCBtZW1iZXIgd2hlbiBkaXNwb3NpbmcgaXQs IHRvIGVuc3VyZSB0aGF0IGl0IHdvbid0IGJlIG1pc3Rha2VubHkgdG91Y2hlZCBhZnRlciB0aGF0 IHBvaW50LgorCisgICAgICAgIFRoaXMgcGF0Y2ggaXMgaW50ZW5kZWQgdG8gcmVzb2x2ZSBmbGFr aW5lc3MgaW4gdGhlIHN0b3JhZ2UgdGVzdHMgaW5jbHVkaW5nOgorICAgICAgICAgIHN0b3JhZ2Uv aW5kZXhlZGRiL21vemlsbGEvaW5kZXhlcy5odG1sCisgICAgICAgICAgc3RvcmFnZS9pbmRleGVk ZGIvbW96aWxsYS9rZXktcmVxdWlyZW1lbnRzLWlubGluZS1hbmQtcGFzc2VkLmh0bWwKKyAgICAg ICAgICBzdG9yYWdlL3dlYnNxbC9tdWx0aXBsZS1kYXRhYmFzZXMtZ2FyYmFnZS1jb2xsZWN0aW9u Lmh0bWwKKworICAgICAgICAqIGJpbmRpbmdzL3Y4L05QVjhPYmplY3QuY3BwOgorICAgICAgICAo V2ViQ29yZTo6ZGlzcG9zZVVuZGVybHlpbmdWOE9iamVjdCk6CisgICAgICAgIFplcm8gdGhlIE5Q T2JqZWN0J3MgdW5kZXJseWluZyByb290T2JqZWN0LgorICAgICAgICAoX05QTl9FdmFsdWF0ZUhl bHBlcik6CisgICAgICAgIEFkZCBjaGVjayB0aGF0IHRoZSB1bmRlcmx5aW5nIFY4IG9iamVjdCBy ZWZlcmVuY2UgaXMgdmFsaWQuCisKIDIwMTItMDctMTAgIFN1ZGFyc2FuYSBOYWdpbmVuaSAgPHN1 ZGFyc2FuYS5uYWdpbmVuaUBsaW51eC5pbnRlbC5jb20+CiAKICAgICAgICAgW0dUS10gRml4IG1l bW9yeSBsZWFrcyBieSBhZG9wdGluZyBhbGxvY2F0aW9uIG9mIEdka1BpeGJ1ZgpkaWZmIC0tZ2l0 IGEvU291cmNlL1dlYkNvcmUvYmluZGluZ3MvdjgvTlBWOE9iamVjdC5jcHAgYi9Tb3VyY2UvV2Vi Q29yZS9iaW5kaW5ncy92OC9OUFY4T2JqZWN0LmNwcAppbmRleCBkNGQ2Y2ZjOWMyOWI3NTU1NTkw MGM1MmI0NWQxMmJkYjNhYWM3YTg4Li42YTc2YmZmZjVmZjkxM2NhMjg5MzljMWJkZTU5ZjQ4NWFj NDRjYmI3IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9iaW5kaW5ncy92OC9OUFY4T2JqZWN0 LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9iaW5kaW5ncy92OC9OUFY4T2JqZWN0LmNwcApAQCAt MTg2LDYgKzE4Niw3IEBAIHZvaWQgZGlzcG9zZVVuZGVybHlpbmdWOE9iamVjdChOUE9iamVjdCog bnBPYmplY3QpCiAjZW5kaWYKICAgICB2OE5wT2JqZWN0LT52OE9iamVjdC5EaXNwb3NlKCk7CiAg ICAgdjhOcE9iamVjdC0+djhPYmplY3QuQ2xlYXIoKTsKKyAgICB2OE5wT2JqZWN0LT5yb290T2Jq ZWN0ID0gMDsKIH0KIAogfSAvLyBuYW1lc3BhY2UgV2ViQ29yZQpAQCAtMzIwLDYgKzMyMSw5IEBA IGJvb2wgX05QTl9FdmFsdWF0ZUhlbHBlcihOUFAgbnBwLCBib29sIHBvcHVwc0FsbG93ZWQsIE5Q T2JqZWN0KiBucE9iamVjdCwgTlBTdHJpCiAKICAgICBpZiAobnBPYmplY3QtPl9jbGFzcyAhPSBu cFNjcmlwdE9iamVjdENsYXNzKQogICAgICAgICByZXR1cm4gZmFsc2U7CisgICAgVjhOUE9iamVj dCogdjhOcE9iamVjdCA9IHJlaW50ZXJwcmV0X2Nhc3Q8VjhOUE9iamVjdCo+KG5wT2JqZWN0KTsK KyAgICBpZiAodjhOcE9iamVjdC0+djhPYmplY3QuSXNFbXB0eSgpKQorICAgICAgICByZXR1cm4g ZmFsc2U7CiAKICAgICB2ODo6SGFuZGxlU2NvcGUgaGFuZGxlU2NvcGU7CiAgICAgdjg6OkhhbmRs ZTx2ODo6Q29udGV4dD4gY29udGV4dCA9IHRvVjhDb250ZXh0KG5wcCwgbnBPYmplY3QpOwo=