47432 2010-10-08 14:38:25 -0700 No longer ASSERT for LayerRenderer in VideoLayerChromium destructor 2010-10-14 11:39:22 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Other OS X 10.5 RESOLVED FIXED P2 Normal --- 0 vrk webkit-unassigned eric hclam jamesr vangelis oldest_to_newest 291874 0 vrk 2010-10-08 14:38:25 -0700 No longer ASSERT for LayerRenderer in VideoLayerChromium destructor 292004 1 70329 vrk 2010-10-08 18:25:34 -0700 Created attachment 70329 Patch 292005 2 vrk 2010-10-08 18:30:44 -0700 Turns out, we can't guarantee that VideoLayerChromiums will not be created with LayerRenderers associated with them, so we need to change the ASSERT to an if after all. In particular, this case can occur if hardware acceleration is supported and initializes correctly, the WebMediaPlayerClientImpl loads correctly, but there is a problem in the media pipeline (such as in demuxing) so the video object is created but never rendered. 292011 3 vrk 2010-10-08 18:36:59 -0700 (In reply to comment #2) > Turns out, we can't guarantee that VideoLayerChromiums will not be created with LayerRenderers associated with them Oops, I meant that we can't guarantee VideoLayerChromiums *will* be created with LayerRenderers associated with them! In other words, there will be non-mistake cases where VideoLayerChromiums are destructed without ever having a LayerRenderer attached to them. 292344 4 70329 abarth 2010-10-10 12:25:00 -0700 Comment on attachment 70329 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=70329&action=review Can we have an test that hits this assert (even periodically)? > WebCore/ChangeLog:17 > - > + This change is spurious and will cause the automatic commit to fail. > WebCore/platform/graphics/chromium/VideoLayerChromium.cpp:191 > + if (layerRenderer()) { Prefer early return. 293028 5 vrk 2010-10-12 11:58:22 -0700 (In reply to comment #4) > (From update of attachment 70329 [details]) > > Can we have an test that hits this assert (even periodically)? I'm not sure how to do this in a layout test. What I would need to write is some sort of JavaScript to force WebKit to destruct a WebMediaPlayer... In a UI test this would just involve forcing the browser to do a refresh, but in JS "window.location.reload(true);" is not the same. Any ideas? I can ask my teammates as well. 293049 6 hclam 2010-10-12 12:26:22 -0700 There are already layout tests that inject a video element and then remove it from the DOM tree. However test_shell or DRT for chrome doesn't support accelerated compositing, so this bug is not triggered. I think we are working on getting that infrastructure. 293079 7 jamesr 2010-10-12 13:09:07 -0700 test_shell and DRT both support accelerated compositing right now (using Mesa). Pass --accelerated-compositing to new-run-webkit-tests to turn this on. We're in the process of configuring the bots to run tests in this configuration by default, but in the meantime you should be able to construct a test that triggers the issue when run locally. I think it's really important to have test coverage for this given how many crashes there have already been in this part of the codebase. 293267 8 vrk 2010-10-12 21:49:29 -0700 (In reply to comment #6) > There are already layout tests that inject a video element and then remove it from the DOM tree. But does this destroy the VideoLayerChromium? When I was playing around with JavaScript on my local build of Chrome (that is, not in test_shell or drt), it seemed like removing the video element from the DOM tree did not destruct the WebMediaPlayer and therefore did not destruct the VideoLayerChromium; only refreshing the page seemed to destroy the layer. I could have done something wrong though. Can you show me which test(s) will actually destroy the VideoLayerChromium? On the other hand, if refreshing the page is the only way to destroy the VideoLayerChromium, then I'm still not sure how to write a layout test for this even with Mesa since I'm not sure how to trigger this code path. 293305 9 hclam 2010-10-13 01:32:41 -0700 (In reply to comment #8) > (In reply to comment #6) > > There are already layout tests that inject a video element and then remove it from the DOM tree. > > But does this destroy the VideoLayerChromium? When I was playing around with JavaScript on my local build of Chrome (that is, not in test_shell or drt), it seemed like removing the video element from the DOM tree did not destruct the WebMediaPlayer and therefore did not destruct the VideoLayerChromium; only refreshing the page seemed to destroy the layer. I could have done something wrong though. Can you show me which test(s) will actually destroy the VideoLayerChromium? > Remove a video tag does destroy WebMediaPlayer. I tested this with test_shell. media/controls-after-reload.html will destroy the WebMediaPlayer. And if --enable-accelerated-compositing is used VideoLayerChromium is also destroyed. So I think it's a different code path that triggers the crash. > On the other hand, if refreshing the page is the only way to destroy the VideoLayerChromium, then I'm still not sure how to write a layout test for this even with Mesa since I'm not sure how to trigger this code path. (In reply to comment #8) > (In reply to comment #6) > > There are already layout tests that inject a video element and then remove it from the DOM tree. > > But does this destroy the VideoLayerChromium? When I was playing around with JavaScript on my local build of Chrome (that is, not in test_shell or drt), it seemed like removing the video element from the DOM tree did not destruct the WebMediaPlayer and therefore did not destruct the VideoLayerChromium; only refreshing the page seemed to destroy the layer. I could have done something wrong though. Can you show me which test(s) will actually destroy the VideoLayerChromium? > > On the other hand, if refreshing the page is the only way to destroy the VideoLayerChromium, then I'm still not sure how to write a layout test for this even with Mesa since I'm not sure how to trigger this code path. 293338 10 hclam 2010-10-13 02:58:34 -0700 I tried to create a new layout test for this I can't figure a way to test this without making changes to test_shell. There are some conditions to trigger this: 1. A video is loaded and the first 2 frames are decoded. 2. Either WebMediaPlayer::repaint is not called or the repaint never reach LayerRendererChromium. (1) is easy. (2) is hard to do, it is possible that repaint is fired but before it reaches LayerRendererChromium we destroy WebMediaPlayer, this is very time dependent and is not realistic. What is really causing this crash is that LayerRendererChromium failed to be initialized in a valid GL context, so we created a VideoLayerChromium and never associate it with a LayerRendererChromium. I wonder if we can modify LayoutTestController to allow tests to cripple GL context initialization. Or we add a flag to run test_shell with --fail-mesa-initialization and --enable-accelerated-compositing to make sure tests don't crash. Besides testing, instead of early return if we have a good way to check if compositor is inactive we can skip creating VideoLayerChromium, any thoughts on this? 293468 11 vangelis 2010-10-13 09:48:26 -0700 > > Besides testing, instead of early return if we have a good way to check if compositor is inactive we can skip creating VideoLayerChromium, any thoughts on this? As the code stands right now, the VideoLayerChromium gets created after checking for supportsAcceleratedRendering(). However, supportsAcceleratedRendering() uses the value from contentRenderer()->compositor()->hasAcceleratedCompositing() captured when the WebMediaPlayerClientImpl is first created which isn't necessarily accurate. One possibility would be to not cache that return value and try to get it every time supportsAcceleratedRendering(). Hopefully this will give a more accurate indication on whether the LayerRendererChromium was successfully created. Even that though isn't guaranteed to be accurate, especially if readyStateChanged() gets called before the compositor for the page is set up. Overall I think the safest and correct solution is the one currently implemented in the patch. I think the proper way to test this and other similar failures would be to have a mode in DRT that simulates the failure to create a GL context so that we can test that all the fallback paths work properly. 293477 12 vangelis 2010-10-13 09:57:22 -0700 (In reply to comment #11) > I think the proper way to test this and other similar failures would be to have a mode in DRT that simulates the failure to create a GL context so that we can test that all the fallback paths work properly. Entered in chromium bug tracker as: http://code.google.com/p/chromium/issues/detail?id=59059 293539 13 vangelis 2010-10-13 11:11:12 -0700 (In reply to comment #12) > (In reply to comment #11) > > > I think the proper way to test this and other similar failures would be to have a mode in DRT that simulates the failure to create a GL context so that we can test that all the fallback paths work properly. > > Entered in chromium bug tracker as: > http://code.google.com/p/chromium/issues/detail?id=59059 James, Adam: Any chance we can check this patch in (this is now a top crasher for chromium) and deal with building the testing infrastructure for the software fallback as a separate issue? It falls somewhat outside the scope of this bug. 293548 14 70633 vrk 2010-10-13 11:23:17 -0700 Created attachment 70633 Patch 293566 15 jamesr 2010-10-13 11:40:01 -0700 VideoLayerChromium shutdown has been the top crasher for the last few weeks now and we've been through several iterations of fixes but are still finding issues. I think it's really high priority to get more test coverage here or we'll keep running in to more issues. 293568 16 70640 vrk 2010-10-13 11:44:16 -0700 Created attachment 70640 Patch 293632 17 vangelis 2010-10-13 12:42:42 -0700 (In reply to comment #15) > VideoLayerChromium shutdown has been the top crasher for the last few weeks now and we've been through several iterations of fixes but are still finding issues. I think it's really high priority to get more test coverage here or we'll keep running in to more issues. Agreed on adding tests for this type of situation. Assuming that the failure is on devices where we fail to create a GL context I think the proper testing needs to happen at a different level and that's why I believe it's outside the scope of this CL. I don't have any good ideas on how, from JS only, to trigger a failure to create a GL context. We could delay checking this in until we adjust our testing infrastructure to simulate a GL context creation failure and run through all our tests as I suggested in the chromium bug but I find this to be counter productive. This failure could be masking other video issues which we won't get to find until this particular crash is resolved. 293742 18 70640 jamesr 2010-10-13 15:19:32 -0700 Comment on attachment 70640 Patch Patch is fine, let's move the discussion about testing to another bug. 293755 19 hclam 2010-10-13 15:32:18 -0700 Starting a new bug to discuss how we can make our tools / infrastructure better: https://bugs.webkit.org/show_bug.cgi?id=47625 293780 20 hclam 2010-10-13 15:51:46 -0700 Committed as http://trac.webkit.org/changeset/69706. 294243 21 eric 2010-10-14 11:39:22 -0700 Please close bugs after committing. webkit-patch land-from-bug will do that for you (as will webkit-patch land). 70329 2010-10-08 18:25:34 -0700 2010-10-13 11:23:14 -0700 Patch bug-47432-20101008182533.patch text/plain 2077 vrk ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg NGM0ZjhiODRkYmZkNWZlYjc3ZTc0MzQ3ODY4MGM2NGE5ZWY0OWJkMy4uOTEzNTBmYTdlMjlhNDMw YzBkZGIzN2RkZjQwYmI0YjRmOTlmMDM1ZSAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cK KysrIGIvV2ViQ29yZS9DaGFuZ2VMb2cKQEAgLTEsMTAgKzEsMjAgQEAKKzIwMTAtMTAtMDggIFZp Y3RvcmlhIEtpcnN0ICA8dnJrQGdvb2dsZS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgTm8gbG9uZ2VyIEFTU0VSVCBmb3IgTGF5ZXJSZW5kZXJl ciBpbiBWaWRlb0xheWVyQ2hyb21pdW0gZGVzdHJ1Y3RvcgorICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDc0MzIKKworICAgICAgICAqIHBsYXRmb3JtL2dy YXBoaWNzL2Nocm9taXVtL1ZpZGVvTGF5ZXJDaHJvbWl1bS5jcHA6CisgICAgICAgIChXZWJDb3Jl OjpWaWRlb0xheWVyQ2hyb21pdW06OmNsZWFudXBSZXNvdXJjZXMpOgorCiAyMDEwLTEwLTA4ICBN aWhhaSBQYXJwYXJpdGEgIDxtaWhhaXBAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJldmlld2Vk IGJ5IEFkYW0gQmFydGguCiAKICAgICAgICAgcG9wc3RhdGUgZXZlbnRzIGFyZSBsb3N0IHdoZW4g bmV0d29yayBjb25uZWN0aW9uIGlzIGluIHByb2dyZXNzCiAgICAgICAgIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD00Mjk0MAotICAgICAgICAKKwogICAgICAgICBJbnN0 ZWFkIG9mIGNoZWNraW5nIEZyYW1lTG9hZGVyOjppc0NvbXBsZXRlKCkgKHdoaWNoIGlzbid0IHRy dWUgaWYgdGhlCiAgICAgICAgIGRvY3VtZW50J3MgcmVzb3VyY2UgbG9hZGVyIGhhcyByZXF1ZXN0 cyBvdXRzdGFuZGluZyksIGNoZWNrIHRoYXQgdGhlCiAgICAgICAgIGRvY3VtZW50J3MgcmVhZHlT dGF0ZSBpcyBjb21wbGV0ZSwgYXMgdGhlIHNwZWMgc2F5cy4KZGlmZiAtLWdpdCBhL1dlYkNvcmUv cGxhdGZvcm0vZ3JhcGhpY3MvY2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcCBiL1dlYkNv cmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcAppbmRl eCAwMWI0ZDZlODE5Y2I3MWIwZWNmYWI2NjRjM2M2ZGM3ZjZhYTUxNjRlLi40M2ZjYTM0NGNlNTEy NzUxNzVjOGE5NjkzMWIxODg3ZjYwNmNlNTI0IDEwMDY0NAotLS0gYS9XZWJDb3JlL3BsYXRmb3Jt L2dyYXBoaWNzL2Nocm9taXVtL1ZpZGVvTGF5ZXJDaHJvbWl1bS5jcHAKKysrIGIvV2ViQ29yZS9w bGF0Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9WaWRlb0xheWVyQ2hyb21pdW0uY3BwCkBAIC0xODgs MTEgKzE4OCwxMiBAQCBWaWRlb0xheWVyQ2hyb21pdW06On5WaWRlb0xheWVyQ2hyb21pdW0oKQog dm9pZCBWaWRlb0xheWVyQ2hyb21pdW06OmNsZWFudXBSZXNvdXJjZXMoKQogewogICAgIHJlbGVh c2VDdXJyZW50RnJhbWUoKTsKLSAgICBBU1NFUlQobGF5ZXJSZW5kZXJlcigpKTsKLSAgICBHcmFw aGljc0NvbnRleHQzRCogY29udGV4dCA9IGxheWVyUmVuZGVyZXJDb250ZXh0KCk7Ci0gICAgZm9y ICh1bnNpZ25lZCBwbGFuZSA9IDA7IHBsYW5lIDwgVmlkZW9GcmFtZUNocm9taXVtOjptYXhQbGFu ZXM7IHBsYW5lKyspIHsKLSAgICAgICAgaWYgKG1fdGV4dHVyZXNbcGxhbmVdKQotICAgICAgICAg ICAgR0xDKGNvbnRleHQsIGNvbnRleHQtPmRlbGV0ZVRleHR1cmUobV90ZXh0dXJlc1twbGFuZV0p KTsKKyAgICBpZiAobGF5ZXJSZW5kZXJlcigpKSB7CisgICAgICAgIEdyYXBoaWNzQ29udGV4dDNE KiBjb250ZXh0ID0gbGF5ZXJSZW5kZXJlckNvbnRleHQoKTsKKyAgICAgICAgZm9yICh1bnNpZ25l ZCBwbGFuZSA9IDA7IHBsYW5lIDwgVmlkZW9GcmFtZUNocm9taXVtOjptYXhQbGFuZXM7IHBsYW5l KyspIHsKKyAgICAgICAgICAgIGlmIChtX3RleHR1cmVzW3BsYW5lXSkKKyAgICAgICAgICAgICAg ICBHTEMoY29udGV4dCwgY29udGV4dC0+ZGVsZXRlVGV4dHVyZShtX3RleHR1cmVzW3BsYW5lXSkp OworICAgICAgICB9CiAgICAgfQogfQogCg== 70633 2010-10-13 11:23:17 -0700 2010-10-13 11:44:12 -0700 Patch bug-47432-20101013112316.patch text/plain 1390 vrk ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg MGY5ZDc3YzY5YWE0NzUwOWRmMzY4MTE1ODUxNjFlOWNiZWRlNzcxNC4uMGM0MTEwZTk5ZGFhYjQ3 N2ZiMDRmMjVhODk0ZGIzMDIyNmNhOGI5MCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cK KysrIGIvV2ViQ29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBAQAorMjAxMC0xMC0xMyAgVmlj dG9yaWEgS2lyc3QgIDx2cmtAZ29vZ2xlLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBObyBsb25nZXIgQVNTRVJUIGZvciBMYXllclJlbmRlcmVy IGluIFZpZGVvTGF5ZXJDaHJvbWl1bSBkZXN0cnVjdG9yCisgICAgICAgIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD00NzQzMgorCisgICAgICAgICogcGxhdGZvcm0vZ3Jh cGhpY3MvY2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6 OlZpZGVvTGF5ZXJDaHJvbWl1bTo6Y2xlYW51cFJlc291cmNlcyk6CisKIDIwMTAtMTAtMTEgIEdp cmlzaCBSYW1ha3Jpc2huYW4gIDxnaXJpc2hAZm9yd2FyZGJpYXMuaW4+CiAKICAgICAgICAgUmV2 aWV3ZWQgYnkgQW5kZXJzIENhcmxzc29uLgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9wbGF0Zm9ybS9n cmFwaGljcy9jaHJvbWl1bS9WaWRlb0xheWVyQ2hyb21pdW0uY3BwIGIvV2ViQ29yZS9wbGF0Zm9y bS9ncmFwaGljcy9jaHJvbWl1bS9WaWRlb0xheWVyQ2hyb21pdW0uY3BwCmluZGV4IDAxYjRkNmU4 MTljYjcxYjBlY2ZhYjY2NGMzYzZkYzdmNmFhNTE2NGUuLjI0NTA0ZmQ0MTY5ODRhYzMzOWY5NmE3 YmZhZTRkMzhiNTkzMzQ4MGEgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3Mv Y2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcAorKysgYi9XZWJDb3JlL3BsYXRmb3JtL2dy YXBoaWNzL2Nocm9taXVtL1ZpZGVvTGF5ZXJDaHJvbWl1bS5jcHAKQEAgLTE4OCw3ICsxODgsOSBA QCBWaWRlb0xheWVyQ2hyb21pdW06On5WaWRlb0xheWVyQ2hyb21pdW0oKQogdm9pZCBWaWRlb0xh eWVyQ2hyb21pdW06OmNsZWFudXBSZXNvdXJjZXMoKQogewogICAgIHJlbGVhc2VDdXJyZW50RnJh bWUoKTsKLSAgICBBU1NFUlQobGF5ZXJSZW5kZXJlcigpKTsKKyAgICBpZiAoIWxheWVyUmVuZGVy ZXIoKSkKKyAgICAgIHJldHVybjsKKwogICAgIEdyYXBoaWNzQ29udGV4dDNEKiBjb250ZXh0ID0g bGF5ZXJSZW5kZXJlckNvbnRleHQoKTsKICAgICBmb3IgKHVuc2lnbmVkIHBsYW5lID0gMDsgcGxh bmUgPCBWaWRlb0ZyYW1lQ2hyb21pdW06Om1heFBsYW5lczsgcGxhbmUrKykgewogICAgICAgICBp ZiAobV90ZXh0dXJlc1twbGFuZV0pCg== 70640 2010-10-13 11:44:16 -0700 2010-10-13 15:19:32 -0700 Patch bug-47432-20101013114414.patch text/plain 1392 vrk ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg MGY5ZDc3YzY5YWE0NzUwOWRmMzY4MTE1ODUxNjFlOWNiZWRlNzcxNC4uMGM0MTEwZTk5ZGFhYjQ3 N2ZiMDRmMjVhODk0ZGIzMDIyNmNhOGI5MCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cK KysrIGIvV2ViQ29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBAQAorMjAxMC0xMC0xMyAgVmlj dG9yaWEgS2lyc3QgIDx2cmtAZ29vZ2xlLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBObyBsb25nZXIgQVNTRVJUIGZvciBMYXllclJlbmRlcmVy IGluIFZpZGVvTGF5ZXJDaHJvbWl1bSBkZXN0cnVjdG9yCisgICAgICAgIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD00NzQzMgorCisgICAgICAgICogcGxhdGZvcm0vZ3Jh cGhpY3MvY2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6 OlZpZGVvTGF5ZXJDaHJvbWl1bTo6Y2xlYW51cFJlc291cmNlcyk6CisKIDIwMTAtMTAtMTEgIEdp cmlzaCBSYW1ha3Jpc2huYW4gIDxnaXJpc2hAZm9yd2FyZGJpYXMuaW4+CiAKICAgICAgICAgUmV2 aWV3ZWQgYnkgQW5kZXJzIENhcmxzc29uLgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9wbGF0Zm9ybS9n cmFwaGljcy9jaHJvbWl1bS9WaWRlb0xheWVyQ2hyb21pdW0uY3BwIGIvV2ViQ29yZS9wbGF0Zm9y bS9ncmFwaGljcy9jaHJvbWl1bS9WaWRlb0xheWVyQ2hyb21pdW0uY3BwCmluZGV4IDAxYjRkNmU4 MTljYjcxYjBlY2ZhYjY2NGMzYzZkYzdmNmFhNTE2NGUuLjQ2YzczYTFlZjYxYjVjOGE2NmE4NjE3 ZDRkZGE5NzkzY2VhNzlkYTYgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3Mv Y2hyb21pdW0vVmlkZW9MYXllckNocm9taXVtLmNwcAorKysgYi9XZWJDb3JlL3BsYXRmb3JtL2dy YXBoaWNzL2Nocm9taXVtL1ZpZGVvTGF5ZXJDaHJvbWl1bS5jcHAKQEAgLTE4OCw3ICsxODgsOSBA QCBWaWRlb0xheWVyQ2hyb21pdW06On5WaWRlb0xheWVyQ2hyb21pdW0oKQogdm9pZCBWaWRlb0xh eWVyQ2hyb21pdW06OmNsZWFudXBSZXNvdXJjZXMoKQogewogICAgIHJlbGVhc2VDdXJyZW50RnJh bWUoKTsKLSAgICBBU1NFUlQobGF5ZXJSZW5kZXJlcigpKTsKKyAgICBpZiAoIWxheWVyUmVuZGVy ZXIoKSkKKyAgICAgICAgcmV0dXJuOworCiAgICAgR3JhcGhpY3NDb250ZXh0M0QqIGNvbnRleHQg PSBsYXllclJlbmRlcmVyQ29udGV4dCgpOwogICAgIGZvciAodW5zaWduZWQgcGxhbmUgPSAwOyBw bGFuZSA8IFZpZGVvRnJhbWVDaHJvbWl1bTo6bWF4UGxhbmVzOyBwbGFuZSsrKSB7CiAgICAgICAg IGlmIChtX3RleHR1cmVzW3BsYW5lXSkK