153194 2016-01-17 06:09:08 -0800 REGRESSION(r192773): [GTK] maps.google.com unresponsive/stalls since r192773 2016-02-01 05:23:59 -0800 1 1 1 Unclassified WebKit WebKitGTK Other PC Linux RESOLVED FIXED P2 Normal --- 1 fosero webkit-unassigned agomez bugs-noreply calvaris cgarcia guillaume.webkit mcatanzaro oldest_to_newest 1156283 0 fosero 2016-01-17 06:09:08 -0800 Going to maps.google.com results in a default map being shown and then the impossibility to drag the map or input a location during or after loading. Resizing the window shows no paint updates for the particular tab in epiphany, however the tab can be closed (just takes a while). As suggested on IRC I've built webkit both with and without opengl enabled, this made no difference. 1156630 1 guillaume.webkit 2016-01-19 10:27:49 -0800 I can confirm this bug, happening for example on: - http://maps.google.com - https://www.google.com/recaptcha/api2/demo after clicking on the recaptcha - https://reviewable.io/reviews/kozea/weasyprint/291#-:-K7vq1bdt8Ke36KDOXBW:-1975054978 These pages are rendered correctly for me with 2.11.1. 1157008 2 guillaume.webkit 2016-01-20 12:22:48 -0800 2.11.4 doesn't fix this bug. 1157280 3 mcatanzaro 2016-01-21 06:33:50 -0800 *** Bug 153302 has been marked as a duplicate of this bug. *** 1157281 4 mcatanzaro 2016-01-21 06:35:03 -0800 The "good" news is that this got backported to 2.10, which should make it easier to find out which commit is to blame. The bad news is that this got backported. Honestly I think we are being a bit too aggressive with the number of commits backported to stable.... 1157284 5 cgarcia 2016-01-21 06:49:52 -0800 (In reply to comment #4) > The "good" news is that this got backported to 2.10, which should make it > easier to find out which commit is to blame. > > The bad news is that this got backported. Honestly I think we are being a > bit too aggressive with the number of commits backported to stable.... I don't think it's a matter of number of commits, we had a lot of commits in this release because it took a bit more time since the laste release. All commits landed are bug fixes, rendering issues, crashes and security bugs. What should I leave out? I always try to avoid major refactorings, or large changes in JSC. For every commit I merge, if it's JSC I run all the javascript tests, if it's a rendering issue or crash referencing layout tests I run those, and if it affects the GTK API I run the GTK API tests. I could still merge a commit that breaks something or regresses, of course, but that wouldn't change if I merged fewer commits. 1157296 6 agomez 2016-01-21 08:07:33 -0800 (In reply to comment #5) ... > I don't think it's a matter of number of commits, we had a lot of commits in > this release because it took a bit more time since the laste release. All > commits landed are bug fixes, rendering issues, crashes and security bugs. > What should I leave out? I always try to avoid major refactorings, or large > changes in JSC. For every commit I merge, if it's JSC I run all the > javascript tests, if it's a rendering issue or crash referencing layout > tests I run those, and if it affects the GTK API I run the GTK API tests. I > could still merge a commit that breaks something or regresses, of course, > but that wouldn't change if I merged fewer commits. I agree it is not the number of commits but maybe the criteria could be slightly changed. What about only merging: * fixes of bugs reported to the stable branch. * security fixes * other kind of fixes that have been already merged in (current_unstable_version - 1) and no regressions have been reported on them. WDYT? 1157297 7 cgarcia 2016-01-21 08:33:44 -0800 (In reply to comment #6) > (In reply to comment #5) > ... > > I don't think it's a matter of number of commits, we had a lot of commits in > > this release because it took a bit more time since the laste release. All > > commits landed are bug fixes, rendering issues, crashes and security bugs. > > What should I leave out? I always try to avoid major refactorings, or large > > changes in JSC. For every commit I merge, if it's JSC I run all the > > javascript tests, if it's a rendering issue or crash referencing layout > > tests I run those, and if it affects the GTK API I run the GTK API tests. I > > could still merge a commit that breaks something or regresses, of course, > > but that wouldn't change if I merged fewer commits. > > I agree it is not the number of commits but maybe the criteria could be > slightly changed. > > What about only merging: > * fixes of bugs reported to the stable branch. > * security fixes > * other kind of fixes that have been already merged in > (current_unstable_version - 1) and no regressions have been reported on them. > > WDYT? That doesn't fix anything either, because for example in this particular case we don't know which commit in trunk broke maps.google.com. I prefer to fix 10 issues and introduce 1 regression than fixing 5 issues with no regressions. In any case I always try to avoid merging commits that have been recently committed in trunk, so I'm doing something similar already in the end. 1157300 8 agomez 2016-01-21 08:57:23 -0800 (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > ... > > > I don't think it's a matter of number of commits, we had a lot of commits in > > > this release because it took a bit more time since the laste release. All > > > commits landed are bug fixes, rendering issues, crashes and security bugs. > > > What should I leave out? I always try to avoid major refactorings, or large > > > changes in JSC. For every commit I merge, if it's JSC I run all the > > > javascript tests, if it's a rendering issue or crash referencing layout > > > tests I run those, and if it affects the GTK API I run the GTK API tests. I > > > could still merge a commit that breaks something or regresses, of course, > > > but that wouldn't change if I merged fewer commits. > > > > I agree it is not the number of commits but maybe the criteria could be > > slightly changed. > > > > What about only merging: > > * fixes of bugs reported to the stable branch. > > * security fixes > > * other kind of fixes that have been already merged in > > (current_unstable_version - 1) and no regressions have been reported on them. > > > > WDYT? > > That doesn't fix anything either, because for example in this particular > case we don't know which commit in trunk broke maps.google.com. I prefer to > fix 10 issues and introduce 1 regression than fixing 5 issues with no > regressions. In any case I always try to avoid merging commits that have > been recently committed in trunk, so I'm doing something similar already in > the end. Obviously, you will always will have the risk of introducing regressions. That's never guaranteed. The question is which is the priority in stable and I disagree with you. You should try as hard as possible to avoid introducing regressions so I would favor fixing 5 issues with no regressions than the other way around. Anyway, just my opinion. 1157311 9 mcatanzaro 2016-01-21 09:32:48 -0800 By any chance, is there anyone at the office with ICC who would be willing to bisect this between 2.10.5 and 2.10.4? 1157420 10 agomez 2016-01-21 14:09:35 -0800 (In reply to comment #9) > By any chance, is there anyone at the office with ICC who would be willing > to bisect this between 2.10.5 and 2.10.4? I'm getting to it ... 1157606 11 cgarcia 2016-01-21 23:46:35 -0800 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > ... > > > > I don't think it's a matter of number of commits, we had a lot of commits in > > > > this release because it took a bit more time since the laste release. All > > > > commits landed are bug fixes, rendering issues, crashes and security bugs. > > > > What should I leave out? I always try to avoid major refactorings, or large > > > > changes in JSC. For every commit I merge, if it's JSC I run all the > > > > javascript tests, if it's a rendering issue or crash referencing layout > > > > tests I run those, and if it affects the GTK API I run the GTK API tests. I > > > > could still merge a commit that breaks something or regresses, of course, > > > > but that wouldn't change if I merged fewer commits. > > > > > > I agree it is not the number of commits but maybe the criteria could be > > > slightly changed. > > > > > > What about only merging: > > > * fixes of bugs reported to the stable branch. > > > * security fixes > > > * other kind of fixes that have been already merged in > > > (current_unstable_version - 1) and no regressions have been reported on them. > > > > > > WDYT? > > > > That doesn't fix anything either, because for example in this particular > > case we don't know which commit in trunk broke maps.google.com. I prefer to > > fix 10 issues and introduce 1 regression than fixing 5 issues with no > > regressions. In any case I always try to avoid merging commits that have > > been recently committed in trunk, so I'm doing something similar already in > > the end. > > Obviously, you will always will have the risk of introducing regressions. > That's never guaranteed. The question is which is the priority in stable and > I disagree with you. I don't think that's the question, the question is whether I could have avoided the regression using a different merge strategy. > You should try as hard as possible to avoid introducing > regressions so I would favor fixing 5 issues with no regressions than the > other way around. I already try as hard as possible to avoid introducing regressions, the fact that I prefer to fix 10 bugs instead of 5 and introduce 1 regression doesn't mean I'm careless when merging commits. And the key point, again is that I couldn't have avoided this regression just by being more careful. The only way to be more careful is having a bot that runs all the tests for every commit merged in the stable branch, but that would be a lot more work, and it woulnd't be enough either. Again this regression was not caught by our bots in trunk either. And of course I can't run all the tests for every merge myself, 2.10.5 took me 3 days full time merging commits, so I would need 3 weeks to do the same running the tests. > Anyway, just my opinion. 1157607 12 agomez 2016-01-22 00:12:38 -0800 (In reply to comment #11) ... > I already try as hard as possible to avoid introducing regressions, the fact > that I prefer to fix 10 bugs instead of 5 and introduce 1 regression doesn't > mean I'm careless when merging commits. And the key point, again is that I > couldn't have avoided this regression just by being more careful. The only > way to be more careful is having a bot that runs all the tests for every > commit merged in the stable branch, but that would be a lot more work, and > it woulnd't be enough either. Again this regression was not caught by our > bots in trunk either. And of course I can't run all the tests for every > merge myself, 2.10.5 took me 3 days full time merging commits, so I would > need 3 weeks to do the same running the tests. I think we are talking about different things. You are talking about running tests and I'm talking about having a space of time in which the changes introduced by the fixes are tested by real users. That scenario I can only see that happening is if the changes are first introduced in an unstable release and enough time is left until being also merged in a stable release. And I know that doing so doesn't guarantee that regression won't still be introduced but I think it is a change in the merging policy that can help a lot to prevent that. 1157608 13 agomez 2016-01-22 00:13:55 -0800 (In reply to comment #10) > (In reply to comment #9) > > By any chance, is there anyone at the office with ICC who would be willing > > to bisect this between 2.10.5 and 2.10.4? > > I'm getting to it ... At least, int he 2.10 series, the regression was introduced by: https://trac.webkit.org/changeset/195046 1157663 14 mcatanzaro 2016-01-22 07:20:00 -0800 Thank you Andres! I don't think more time in the unstable series would have helped; we had two users report this was broken in unstable, so clearly there was enough time in unstable. Carlos, I think a different merge strategy might have helped in this case indeed. I would never have guessed "[GLIB] Implement garbage collector timers" would have introduced a bug, but when I was looking at the backports a few days ago I noted this one in particular and was confused why it was selected, since it's a large amount of code not fixing any particular issue, even though it looked probably harmless. I would have avoided the RenderThemeGtk/ScrollbarThemeGtk changes (probably harmless, but huge code changes with no benefit to users), the recent XSSAuditor changes (pushed quite recently, would have held off at least until 2.10.6), Martin's hyphenation fix (probably harmless, but enabling a new feature that we've never supported before), the MIPS fixes and OS X build fixes (just to have fewer commits in stable).... Still, this is art and not science, the only way to avoid regressions is to not backport anything. Thank you for the hard work on the stable release; I am excited in particular for the scrollbar fix! 1157664 15 agomez 2016-01-22 07:29:36 -0800 (In reply to comment #14) > Thank you Andres! > > I don't think more time in the unstable series would have helped; we had two > users report this was broken in unstable, so clearly there was enough time > in unstable. With more time a bisect could have already been done in unstable to find the guilty commit and not having chosen it for merge in stable. Anyway, I agree in the rest of what you say. I think it would be better to omit fixes that are not a clear benefit in stable and involve big changes. 1157672 16 cgarcia 2016-01-22 08:40:43 -0800 (In reply to comment #14) > Thank you Andres! Yes, thank you! > I don't think more time in the unstable series would have helped; we had two > users report this was broken in unstable, so clearly there was enough time > in unstable. > > Carlos, I think a different merge strategy might have helped in this case > indeed. I would never have guessed "[GLIB] Implement garbage collector > timers" would have introduced a bug, but when I was looking at the backports > a few days ago I noted this one in particular and was confused why it was > selected, since it's a large amount of code not fixing any particular issue, > even though it looked probably harmless. I also had doubts when I merged it, but I remembered that right after landing this in trunk the perf bot stopped crashing, and I also considered this harmless enough to merge it, just in case it fixed anything and assuming it didn't break anything. And I was wrong, but again, I would do it again. It's not that I merged this without even thinking about it, I did, and I ran the tests, but unfortunately it broke a single website. > I would have avoided the RenderThemeGtk/ScrollbarThemeGtk changes (probably > harmless, but huge code changes with no benefit to users), Well, if being able to render forms with GTK+ 2.20 doesn't benefit the users... > the recent > XSSAuditor changes (pushed quite recently, would have held off at least > until 2.10.6), Security fixes, no, those are high priority for me. That would work I had time to make stable releases every 2 or 3 weeks, but that's not the case, so security fixes always go in. > Martin's hyphenation fix (probably harmless, but enabling a > new feature that we've never supported before), Exactly because we released 2.10 claiming a feature that doesn't work, we should definitely fix it. > the MIPS fixes and OS X > build fixes (just to have fewer commits in stable).... I guess MIPS and OSX users won't agree with you here either. > Still, this is art and not science, the only way to avoid regressions is to > not backport anything. Thank you for the hard work on the stable release; I > am excited in particular for the scrollbar fix! 1158296 17 269745 cgarcia 2016-01-25 06:59:45 -0800 Created attachment 269745 Patch I confirm that this patch also fixes bug #152340 and it could also fix the huge memory leaks reported with some sites, since we were not doing any garbage collection on workers at all before. 1158317 18 269745 mcatanzaro 2016-01-25 07:47:39 -0800 Comment on attachment 269745 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=269745&action=review Wow, nice job. How did you debug this? Are you planning a 2.10.6 update soon for this? (I decided to stick with 2.10.4 in Fedora due to this issue.) > Source/WebCore/ChangeLog:19 > + schdule their sources. And then we need to check if there are schdule -> schedule > Source/WebCore/workers/WorkerRunLoop.cpp:151 > + if (g_main_context_pending(g_main_context_get_thread_default())) This should be: if (g_main_context_pending(mainContext)) 1158320 19 mcatanzaro 2016-01-25 07:54:39 -0800 *** Bug 152340 has been marked as a duplicate of this bug. *** 1158323 20 cgarcia 2016-01-25 07:59:01 -0800 (In reply to comment #18) > Comment on attachment 269745 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=269745&action=review > > Wow, nice job. How did you debug this? With printf, of course! :-D > Are you planning a 2.10.6 update soon for this? (I decided to stick with > 2.10.4 in Fedora due to this issue.) Yes. > > Source/WebCore/ChangeLog:19 > > + schdule their sources. And then we need to check if there are > > schdule -> schedule Good catch. > > Source/WebCore/workers/WorkerRunLoop.cpp:151 > > + if (g_main_context_pending(g_main_context_get_thread_default())) > > This should be: > > if (g_main_context_pending(mainContext)) Right, forgot to change this. Thanks! 1158342 21 cgarcia 2016-01-25 09:13:57 -0800 Committed r195537: <http://trac.webkit.org/changeset/195537> 1160823 22 269745 zan 2016-02-01 05:06:58 -0800 Comment on attachment 269745 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=269745&action=review > Source/WebCore/workers/WorkerRunLoop.cpp:152 > + if (g_main_context_pending(g_main_context_get_thread_default())) > + g_main_context_iteration(mainContext, FALSE); Is a single iteration enough? Usually this duo works together in a while statement. 1160828 23 cgarcia 2016-02-01 05:23:59 -0800 (In reply to comment #22) > Comment on attachment 269745 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=269745&action=review > > > Source/WebCore/workers/WorkerRunLoop.cpp:152 > > + if (g_main_context_pending(g_main_context_get_thread_default())) > > + g_main_context_iteration(mainContext, FALSE); > > Is a single iteration enough? Usually this duo works together in a while > statement. Yes, any other source pending will be handled in the next iteration. I tried to follow the one iteration, one source rule. If this causes any problem we can dispatch all pending sources in the same iteration. 269745 2016-01-25 06:59:45 -0800 2016-01-25 07:47:39 -0800 Patch wcore-workers-thread-main-context.diff text/plain 3818 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCBlY2ZjNDg0Li4xMzlkNmFhIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMzAg QEAKKzIwMTYtMDEtMjUgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2FsaWEuY29t PgorCisgICAgICAgIFJFR1JFU1NJT04ocjE5Mjc3Myk6IFtHVEtdIG1hcHMuZ29vZ2xlLmNvbSB1 bnJlc3BvbnNpdmUvc3RhbGxzIHNpbmNlIHIxOTI3NzMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1MzE5NAorCisgICAgICAgIFJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpLgorCisgICAgICAgIEluIHIxOTI3NzMgd2UgaW1wbGVtZW50ZWQgdGhlIEph dmFTY3JpcHRDb3JlIGdhcmJhZ2UgY29sbGVjdG9yCisgICAgICAgIHRpbWVycyBmb3IgdGhlIEdU SysgcG9ydC4gVGhvc2UgdGltZXJzIHNjaGVkdWxlIHNvdXJjZXMgaW4gdGhlCisgICAgICAgIGN1 cnJlbnQgdGhyZWFkIGRlZmF1bHQgbWFpbiBjb250ZXh0LCBidXQgSlMgd2ViIHdvcmtlciB0aHJl YWRzCisgICAgICAgIGltcGxlbWVudGF0aW9uIGRvZXNuJ3QgdXNlIFdURjo6UnVuTG9vcCwgYnV0 IGl0cyBvd24gV29ya2VyUnVuTG9vcAorICAgICAgICBjbGFzcyB0aGF0IGRvZXNuJ3QgY3JlYXRl IGEgR01haW5Db250ZXh0IGZvciB0aGUgbmV3IHRocmVhZC4gVGhpcworICAgICAgICBtZWFucyB0 aGF0IGZvciB3ZWIgc2l0ZXMgdXNpbmcgd29ya2Vycywgd2UgYXJlIG5vdyBkb2luZyBnYXJiYWdl CisgICAgICAgIGNvbGxlY3Rpb24gb2Ygd29ya2VyIFZNcyBpbiB0aGUgbWFpbiB0aHJlYWQgd2hp Y2ggZW5kcyB1cCBpbiBhCisgICAgICAgIGRlYWRsb2NrIGF0IHNvbWUgcG9pbnQuIFdlIG5lZWQg dG8gZW5zdXJlIHRoYXQgd29ya2VyIHRocmVhZHMKKyAgICAgICAgY3JlYXRlIGEgR01haW5Db250 ZXh0IGFuZCBwdXNoIGl0IGFzIHRoZSBkZWZhdWx0IG9uZSBmb3IgdGhlCisgICAgICAgIHRocmVh ZCBiZWZvcmUgdGhlIFdvcmtlckdsb2JhbFNjb3BlIGlzIGNyZWF0ZWQuIFRoaXMgd2F5IHdoZW4g dGhlCisgICAgICAgIHdvcmtlciBIZWFwIGlzIGNyZWF0ZWQsIHRoZSBHQyB0aW1lcnMgdXNlIHRo ZSByaWdodCBjb250ZXh0IHRvCisgICAgICAgIHNjaGR1bGUgdGhlaXIgc291cmNlcy4gQW5kIHRo ZW4gd2UgbmVlZCB0byBjaGVjayBpZiB0aGVyZSBhcmUKKyAgICAgICAgc291cmNlcyBwZW5kaW5n IGluIHRoZSB0aHJlYWQgbWFpbiBjb250ZXh0IG9uIGV2ZXJ5IHdvcmtlciBydW4KKyAgICAgICAg bG9vcCBpdGVyYXRpb24uCisKKyAgICAgICAgKiB3b3JrZXJzL1dvcmtlclJ1bkxvb3AuY3BwOgor ICAgICAgICAoV2ViQ29yZTo6V29ya2VyUnVuTG9vcDo6cnVuSW5Nb2RlKToKKyAgICAgICAgKiB3 b3JrZXJzL1dvcmtlclRocmVhZC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpXb3JrZXJUaHJlYWQ6 OndvcmtlclRocmVhZCk6CisKIDIwMTYtMDEtMjQgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dh cmNpYUBpZ2FsaWEuY29tPgogCiAgICAgICAgIFtHVEtdIEltcGxlbWVudCBvdmVybGF5IHNjcm9s bGJhcnMKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3dvcmtlcnMvV29ya2VyUnVuTG9vcC5j cHAgYi9Tb3VyY2UvV2ViQ29yZS93b3JrZXJzL1dvcmtlclJ1bkxvb3AuY3BwCmluZGV4IGU1NDY2 ZGIuLjMxOTM4YTUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3dvcmtlcnMvV29ya2VyUnVu TG9vcC5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvd29ya2Vycy9Xb3JrZXJSdW5Mb29wLmNwcApA QCAtMzksNiArMzksMTAgQEAKICNpbmNsdWRlICJXb3JrZXJUaHJlYWQuaCIKICNpbmNsdWRlIDx3 dGYvQ3VycmVudFRpbWUuaD4KIAorI2lmIFBMQVRGT1JNKEdUSykKKyNpbmNsdWRlIDxnbGliLmg+ CisjZW5kaWYKKwogbmFtZXNwYWNlIFdlYkNvcmUgewogCiBjbGFzcyBXb3JrZXJTaGFyZWRUaW1l ciBmaW5hbCA6IHB1YmxpYyBTaGFyZWRUaW1lciB7CkBAIC0xNDIsNiArMTQ2LDEyIEBAIE1lc3Nh Z2VRdWV1ZVdhaXRSZXN1bHQgV29ya2VyUnVuTG9vcDo6cnVuSW5Nb2RlKFdvcmtlckdsb2JhbFNj b3BlKiBjb250ZXh0LCBjb25zCiAgICAgQVNTRVJUKGNvbnRleHQpOwogICAgIEFTU0VSVChjb250 ZXh0LT50aHJlYWQoKS50aHJlYWRJRCgpID09IGN1cnJlbnRUaHJlYWQoKSk7CiAKKyNpZiBQTEFU Rk9STShHVEspCisgICAgR01haW5Db250ZXh0KiBtYWluQ29udGV4dCA9IGdfbWFpbl9jb250ZXh0 X2dldF90aHJlYWRfZGVmYXVsdCgpOworICAgIGlmIChnX21haW5fY29udGV4dF9wZW5kaW5nKGdf bWFpbl9jb250ZXh0X2dldF90aHJlYWRfZGVmYXVsdCgpKSkKKyAgICAgICAgZ19tYWluX2NvbnRl eHRfaXRlcmF0aW9uKG1haW5Db250ZXh0LCBGQUxTRSk7CisjZW5kaWYKKwogICAgIGRvdWJsZSBk ZWFkbGluZSA9IE1lc3NhZ2VRdWV1ZTxUYXNrPjo6aW5maW5pdGVUaW1lKCk7CiAKICNpZiBVU0Uo Q0YpCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS93b3JrZXJzL1dvcmtlclRocmVhZC5jcHAg Yi9Tb3VyY2UvV2ViQ29yZS93b3JrZXJzL1dvcmtlclRocmVhZC5jcHAKaW5kZXggMGE2MWMzNy4u Yzc3ZWE5YyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvd29ya2Vycy9Xb3JrZXJUaHJlYWQu Y3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3dvcmtlcnMvV29ya2VyVGhyZWFkLmNwcApAQCAtNDQs NiArNDQsMTAgQEAKICNpbmNsdWRlICJXZWJDb3JlVGhyZWFkLmgiCiAjZW5kaWYKIAorI2lmIFBM QVRGT1JNKEdUSykKKyNpbmNsdWRlIDx3dGYvZ2xpYi9HUmVmUHRyLmg+CisjZW5kaWYKKwogbmFt ZXNwYWNlIFdlYkNvcmUgewogCiBzdGF0aWMgU3RhdGljTG9jayB0aHJlYWRTZXRNdXRleDsKQEAg LTEzNCw2ICsxMzgsMTEgQEAgdm9pZCBXb3JrZXJUaHJlYWQ6OndvcmtlclRocmVhZCgpCiAgICAg RmxvYXRpbmdQb2ludEVudmlyb25tZW50OjpzaW5nbGV0b24oKS5wcm9wYWdhdGVNYWluVGhyZWFk RW52aXJvbm1lbnQoKTsKICNlbmRpZgogCisjaWYgUExBVEZPUk0oR1RLKQorICAgIEdSZWZQdHI8 R01haW5Db250ZXh0PiBtYWluQ29udGV4dCA9IGFkb3B0R1JlZihnX21haW5fY29udGV4dF9uZXco KSk7CisgICAgZ19tYWluX2NvbnRleHRfcHVzaF90aHJlYWRfZGVmYXVsdChtYWluQ29udGV4dC5n ZXQoKSk7CisjZW5kaWYKKwogICAgIHsKICAgICAgICAgTG9ja0hvbGRlciBsb2NrKG1fdGhyZWFk Q3JlYXRpb25NdXRleCk7CiAgICAgICAgIG1fd29ya2VyR2xvYmFsU2NvcGUgPSBjcmVhdGVXb3Jr ZXJHbG9iYWxTY29wZShtX3N0YXJ0dXBEYXRhLT5tX3NjcmlwdFVSTCwgbV9zdGFydHVwRGF0YS0+ bV91c2VyQWdlbnQsIG1fc3RhcnR1cERhdGEtPm1fY29udGVudFNlY3VyaXR5UG9saWN5LCBtX3N0 YXJ0dXBEYXRhLT5tX2NvbnRlbnRTZWN1cml0eVBvbGljeVR5cGUsIG1fc3RhcnR1cERhdGEtPm1f dG9wT3JpZ2luLnJlbGVhc2UoKSk7CkBAIC0xNTQsNiArMTYzLDEwIEBAIHZvaWQgV29ya2VyVGhy ZWFkOjp3b3JrZXJUaHJlYWQoKQogCiAgICAgcnVuRXZlbnRMb29wKCk7CiAKKyNpZiBQTEFURk9S TShHVEspCisgICAgZ19tYWluX2NvbnRleHRfcG9wX3RocmVhZF9kZWZhdWx0KG1haW5Db250ZXh0 LmdldCgpKTsKKyNlbmRpZgorCiAgICAgVGhyZWFkSWRlbnRpZmllciB0aHJlYWRJRCA9IG1fdGhy ZWFkSUQ7CiAKICAgICBBU1NFUlQobV93b3JrZXJHbG9iYWxTY29wZS0+aGFzT25lUmVmKCkpOwo=