161481 2016-09-01 01:53:52 -0700 [GTK] Use GTestDBus instead of dbus-launch in WebKitTestBus.cpp 2016-11-02 09:33:38 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Unspecified RESOLVED FIXED P2 Enhancement --- 1 berto webkit-unassigned bugs-noreply cgarcia clopez gustavo mcatanzaro oldest_to_newest 1225294 0 berto 2016-09-01 01:53:52 -0700 This is not a priority, but I'm leaving it here so it can be tracker. Debian is moving towards making dbus-x11 optional. WebKitGTK+ uses dbus-launch in one of its tests. Using GTestDBus instead (as stated in the FIXME comment in the very source file) should solve this problem. More details here: https://lists.debian.org/debian-devel/2016/08/msg00554.html 1246408 1 293416 cgarcia 2016-10-31 06:44:53 -0700 Created attachment 293416 Patch 1246469 2 mcatanzaro 2016-10-31 09:51:20 -0700 Didn't we have a similar patch recently? From Gustavo or Emanuele? What happened to that? 1246470 3 cgarcia 2016-10-31 09:56:35 -0700 I don't know I haven't seen anything in my bug mail, and this is the first patch in this bug. 1246477 4 cgarcia 2016-10-31 10:15:07 -0700 Ah, I guess you mean bug #161135. That doesn't change the use of dbus-launch, both patches are compatible, it's not the same thing 1246487 5 293416 mcatanzaro 2016-10-31 10:50:44 -0700 Comment on attachment 293416 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293416&action=review > Tools/TestWebKitAPI/gtk/WebKit2Gtk/WebKitTestBus.cpp:38 > + g_setenv("DISPLAY", display.data(), FALSE); So the problem here is it's too late to be doing setenv; we've already initialized threads. Some other thread could call getenv at the same time -- there are getenv calls in many many places -- and crash. It's not a theoretical issue, I've seen multiple cases of this crashing gnome-session. 1246489 6 mcatanzaro 2016-10-31 10:52:58 -0700 Although I do see the existing code was doing this already, I would prefer finding a way to fix it. 1246862 7 293416 cgarcia 2016-11-01 02:31:38 -0700 Comment on attachment 293416 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=293416&action=review >> Tools/TestWebKitAPI/gtk/WebKit2Gtk/WebKitTestBus.cpp:38 >> + g_setenv("DISPLAY", display.data(), FALSE); > > So the problem here is it's too late to be doing setenv; we've already initialized threads. Some other thread could call getenv at the same time -- there are getenv calls in many many places -- and crash. It's not a theoretical issue, I've seen multiple cases of this crashing gnome-session. It's not that I want to se the display here, DISPLAY has already been set, but g_test_dbus_up() unsets it unconditionally, so I'm just restoring it because otherwise nothing works (the web process needs DISPLAY to be set to work). This has nothing to do with gnome-session, this only affects the tests. 1246879 8 293416 mcatanzaro 2016-11-01 05:10:24 -0700 Comment on attachment 293416 Patch The problem is that if you do that, the test will randomly crash; we don't need more flaky tests. In fact, since g_test_dbus_up() calls setenv() itself, it suffers from the same problem. We need to be careful to only call such functions (a) at the very top of main(), or (b) when we're really really sure that it's before the first secondary thread has been created, otherwise the test will be flaky. And it's impossible for WebKitTestBus to guarantee where it's used from, so it really needs to not be setting environment variables. Is it even possible to create a GObject without starting secondary threads? 1246884 9 gustavo 2016-11-01 05:50:06 -0700 While the patch from bug 161135 applies along with this one, it does disable this one which I think is undesirable. The result of having both applied would be dbus-run-session be used every time it is available. This solution is a better one, so I'd recommend just going with it, if we can fix the threading concerns. 1247241 10 cgarcia 2016-11-02 00:16:23 -0700 (In reply to comment #8) > Comment on attachment 293416 [details] > Patch > > The problem is that if you do that, the test will randomly crash; we don't > need more flaky tests. Why? Could you show a bt of one of such crashes? Because our current code is calling setenv in the same place, this patch is only replacing the code that GTestDBus with GTestDBus. > In fact, since g_test_dbus_up() calls setenv() > itself, it suffers from the same problem. Exactly, it's not a problem of this patch, but an existing problem (if any) and I have never seen random crashes in the tests using WebKitTestBus. > We need to be careful to only call > such functions (a) at the very top of main(), Which is exactly what happens. This is not public API, this is an internal helper class designed to be used by tests that should do this at the very beginning of beforeAll(): bus = new WebKitTestBus(); if (!bus->run()) return; And beforeAll() is called by main() right after setting up the environment and registering gresources. There isn't any other code before that, nor any other secondary thread created. > or (b) when we're really > really sure that it's before the first secondary thread has been created, > otherwise the test will be flaky. And it's impossible for WebKitTestBus to > guarantee where it's used from, so it really needs to not be setting > environment variables. We are already ensuring both a) and b), and we don't need WebKitTestBus to ensure anything, we just need to use it as it's designed to be used, at the very beginning of beforeAll(). Another option would be to do it unconditionally in main() for all tests, but that could slow down the tests that don't need dbus at all. > Is it even possible to create a GObject without starting secondary threads? There isn't any thread nor GObject created in this case when WebKitTestBus::run is called. 1247244 11 cgarcia 2016-11-02 00:21:28 -0700 (In reply to comment #9) > While the patch from bug 161135 applies along with this one, it does disable > this one which I think is undesirable. The result of having both applied > would be dbus-run-session be used every time it is available. This solution > is a better one, so I'd recommend just going with it, if we can fix the > threading concerns. I'm not sure this patch solves the same problem. The bus started by WebKitTestBus::run() will be leaked if the test crashes, because ~WebKitTestBus() won't be called in that case. So, we can leave this code as fallback when dbus-run-session is not present, or when tests are run manually (without using run-gtk-tests), something that I do a lot. When dbus-run-session is present we simply set m_address, I don't think the patches are mutually exclusive. 1247291 12 mcatanzaro 2016-11-02 05:45:52 -0700 (In reply to comment #10) > Why? Could you show a bt of one of such crashes? Because our current code is > calling setenv in the same place, this patch is only replacing the code that > GTestDBus with GTestDBus. Here's one example of such a crash, with a backtrace: https://bugzilla.gnome.org/show_bug.cgi?id=754951 We had a second case in some important GNOME component recently, but I honestly don't remember where and can't find it now. And we have third one in Endless's private bug tracker right now. > > We need to be careful to only call > > such functions (a) at the very top of main(), > > Which is exactly what happens. This is not public API, this is an internal > helper class designed to be used by tests that should do this at the very > beginning of beforeAll(): > > bus = new WebKitTestBus(); > if (!bus->run()) > return; > > And beforeAll() is called by main() right after setting up the environment > and registering gresources. There isn't any other code before that, nor any > other secondary thread created. OK, then it should be OK, but it is so easy to misuse that I would prefer that you add an assertion to guarantee this. Unfortunately the best example I found requires reading /proc: http://stackoverflow.com/a/13993822/1120203 but it could be done inside #ifndef NDEBUG. Then if that check passes, we can be confident that GLib isn't creating any secondary thread somewhere before the setenv. 1247294 13 cgarcia 2016-11-02 05:52:30 -0700 (In reply to comment #12) > (In reply to comment #10) > > Why? Could you show a bt of one of such crashes? Because our current code is > > calling setenv in the same place, this patch is only replacing the code that > > GTestDBus with GTestDBus. > > Here's one example of such a crash, with a backtrace: > > https://bugzilla.gnome.org/show_bug.cgi?id=754951 > > We had a second case in some important GNOME component recently, but I > honestly don't remember where and can't find it now. And we have third one > in Endless's private bug tracker right now. I don't care about other applications crashing, this bug is about our unit tests, we have done this forever and I've never seen a crash, so I don't understand why you say that this patch is going to be the source of crashes and flaky tests. > > > We need to be careful to only call > > > such functions (a) at the very top of main(), > > > > Which is exactly what happens. This is not public API, this is an internal > > helper class designed to be used by tests that should do this at the very > > beginning of beforeAll(): > > > > bus = new WebKitTestBus(); > > if (!bus->run()) > > return; > > > > And beforeAll() is called by main() right after setting up the environment > > and registering gresources. There isn't any other code before that, nor any > > other secondary thread created. > > OK, then it should be OK, but it is so easy to misuse that I would prefer > that you add an assertion to guarantee this. Unfortunately the best example > I found requires reading /proc: > > http://stackoverflow.com/a/13993822/1120203 > > but it could be done inside #ifndef NDEBUG. Then if that check passes, we > can be confident that GLib isn't creating any secondary thread somewhere > before the setenv. This is private API for unit tests, I don't think we need to complicate things to fix a problem that doesn't exist. 1247326 14 gustavo 2016-11-02 08:08:41 -0700 (In reply to comment #11) > (In reply to comment #9) > > While the patch from bug 161135 applies along with this one, it does disable > > this one which I think is undesirable. The result of having both applied > > would be dbus-run-session be used every time it is available. This solution > > is a better one, so I'd recommend just going with it, if we can fix the > > threading concerns. > > I'm not sure this patch solves the same problem. The bus started by > WebKitTestBus::run() will be leaked if the test crashes, because > ~WebKitTestBus() won't be called in that case. So, we can leave this code as > fallback when dbus-run-session is not present, or when tests are run > manually (without using run-gtk-tests), something that I do a lot. When > dbus-run-session is present we simply set m_address, I don't think the > patches are mutually exclusive. I thought GTestDBus handled cleaning up the dbus daemon process even on crashes? But if you think it's useful to have both and ok to have dbus-run-session used when present I'll go ahead and land it =) 1247329 15 293416 mcatanzaro 2016-11-02 08:36:19 -0700 Comment on attachment 293416 Patch I'm going to give you r+ since you've convinced me that the current code is safe, but I really do think this is fragile and that it would be better to add an assertion, even if the assertion is not straightforward to write. 1247330 16 mcatanzaro 2016-11-02 08:37:24 -0700 (to catch future incorrect use of this class, and to verify that we're right in thinking there is only one thread when this code is executed) 1247344 17 cgarcia 2016-11-02 09:26:40 -0700 (In reply to comment #14) > (In reply to comment #11) > > (In reply to comment #9) > > > While the patch from bug 161135 applies along with this one, it does disable > > > this one which I think is undesirable. The result of having both applied > > > would be dbus-run-session be used every time it is available. This solution > > > is a better one, so I'd recommend just going with it, if we can fix the > > > threading concerns. > > > > I'm not sure this patch solves the same problem. The bus started by > > WebKitTestBus::run() will be leaked if the test crashes, because > > ~WebKitTestBus() won't be called in that case. So, we can leave this code as > > fallback when dbus-run-session is not present, or when tests are run > > manually (without using run-gtk-tests), something that I do a lot. When > > dbus-run-session is present we simply set m_address, I don't think the > > patches are mutually exclusive. > > I thought GTestDBus handled cleaning up the dbus daemon process even on > crashes? But if you think it's useful to have both and ok to have > dbus-run-session used when present I'll go ahead and land it =) You are right, it uses a global watcher that forks a child that watches the parent and kills spawned processes in that case. So, I agree this solution is better, because it also works when tests are run directly without using run-gtk-tests 1247346 18 cgarcia 2016-11-02 09:33:38 -0700 Committed r208284: <http://trac.webkit.org/changeset/208284> 293416 2016-10-31 06:44:53 -0700 2016-11-02 08:36:19 -0700 Patch wk2-dbus-test.diff text/plain 5440 cgarcia ZGlmZiAtLWdpdCBhL1Rvb2xzL0NoYW5nZUxvZyBiL1Rvb2xzL0NoYW5nZUxvZwppbmRleCA1ODI2 NzkyLi41Zjc3ZDAwIDEwMDY0NAotLS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hh bmdlTG9nCkBAIC0xLDUgKzEsMjAgQEAKIDIwMTYtMTAtMzEgIENhcmxvcyBHYXJjaWEgQ2FtcG9z ICA8Y2dhcmNpYUBpZ2FsaWEuY29tPgogCisgICAgICAgIFtHVEtdIFVzZSBHVGVzdERCdXMgaW5z dGVhZCBvZiBkYnVzLWxhdW5jaCBpbiBXZWJLaXRUZXN0QnVzLmNwcAorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTYxNDgxCisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBUZXN0V2ViS2l0QVBJL2d0ay9XZWJL aXQyR3RrL1dlYktpdFRlc3RCdXMuY3BwOgorICAgICAgICAoV2ViS2l0VGVzdEJ1czo6V2ViS2l0 VGVzdEJ1cyk6CisgICAgICAgIChXZWJLaXRUZXN0QnVzOjp+V2ViS2l0VGVzdEJ1cyk6CisgICAg ICAgIChXZWJLaXRUZXN0QnVzOjpydW4pOgorICAgICAgICAoV2ViS2l0VGVzdEJ1czo6Z2V0T3JD cmVhdGVDb25uZWN0aW9uKToKKyAgICAgICAgKFdlYktpdFRlc3RCdXM6OmNyZWF0ZVByb3h5KToK KyAgICAgICAgKiBUZXN0V2ViS2l0QVBJL2d0ay9XZWJLaXQyR3RrL1dlYktpdFRlc3RCdXMuaDoK KworMjAxNi0xMC0zMSAgQ2FybG9zIEdhcmNpYSBDYW1wb3MgIDxjZ2FyY2lhQGlnYWxpYS5jb20+ CisKICAgICAgICAgTmV0d29ya1Nlc3Npb246IE5ldHdvcmsgcHJvY2VzcyBjcmFzaCB3aGVuIGNv bnZlcnRpbmcgbWFpbiByZXNvdXJjZSB0byBkb3dubG9hZAogICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTY0MjIwCiAKZGlmZiAtLWdpdCBhL1Rvb2xzL1Rl c3RXZWJLaXRBUEkvZ3RrL1dlYktpdDJHdGsvV2ViS2l0VGVzdEJ1cy5jcHAgYi9Ub29scy9UZXN0 V2ViS2l0QVBJL2d0ay9XZWJLaXQyR3RrL1dlYktpdFRlc3RCdXMuY3BwCmluZGV4IDFjZjI0MTQu Ljg4NDU2Y2UgMTAwNjQ0Ci0tLSBhL1Rvb2xzL1Rlc3RXZWJLaXRBUEkvZ3RrL1dlYktpdDJHdGsv V2ViS2l0VGVzdEJ1cy5jcHAKKysrIGIvVG9vbHMvVGVzdFdlYktpdEFQSS9ndGsvV2ViS2l0Mkd0 ay9XZWJLaXRUZXN0QnVzLmNwcApAQCAtMjAsNTMgKzIwLDIzIEBACiAjaW5jbHVkZSAiY29uZmln LmgiCiAjaW5jbHVkZSAiV2ViS2l0VGVzdEJ1cy5oIgogCi0jaW5jbHVkZSA8d3RmL2dsaWIvR1Vu aXF1ZVB0ci5oPgotI2luY2x1ZGUgPHd0Zi90ZXh0L1dURlN0cmluZy5oPgotCiBXZWJLaXRUZXN0 QnVzOjpXZWJLaXRUZXN0QnVzKCkKLSAgICA6IG1fcGlkKC0xKQorICAgIDogbV9idXMoYWRvcHRH UmVmKGdfdGVzdF9kYnVzX25ldyhHX1RFU1RfREJVU19OT05FKSkpCiB7CiB9CiAKLWJvb2wgV2Vi S2l0VGVzdEJ1czo6cnVuKCkKK1dlYktpdFRlc3RCdXM6On5XZWJLaXRUZXN0QnVzKCkKIHsKLSAg ICAvLyBGSVhNRTogVXNlIEdUZXN0REJ1cyB3aGVuIHdlIGJ1bXAgZ2xpYiB0byAyLjM0LgotICAg IEdVbmlxdWVQdHI8Y2hhcj4gZGJ1c0xhdW5jaChnX2ZpbmRfcHJvZ3JhbV9pbl9wYXRoKCJkYnVz LWxhdW5jaCIpKTsKLSAgICBpZiAoIWRidXNMYXVuY2gpIHsKLSAgICAgICAgZ193YXJuaW5nKCJF cnJvciBzdGFydGluZyBEQlVTIGRhZW1vbjogZGJ1cy1sYXVuY2ggbm90IGZvdW5kIGluIHBhdGgi KTsKLSAgICAgICAgcmV0dXJuIGZhbHNlOwotICAgIH0KLQotICAgIEdVbmlxdWVPdXRQdHI8Y2hh cj4gb3V0cHV0OwotICAgIEdVbmlxdWVPdXRQdHI8R0Vycm9yPiBlcnJvcjsKLSAgICBpZiAoIWdf c3Bhd25fY29tbWFuZF9saW5lX3N5bmMoZGJ1c0xhdW5jaC5nZXQoKSwgJm91dHB1dC5vdXRQdHIo KSwgMCwgMCwgJmVycm9yLm91dFB0cigpKSkgewotICAgICAgICBnX3dhcm5pbmcoIkVycm9yIHN0 YXJ0aW5nIERCVVMgZGFlbW9uOiAlcyIsIGVycm9yLT5tZXNzYWdlKTsKLSAgICAgICAgcmV0dXJu IGZhbHNlOwotICAgIH0KLQotICAgIFN0cmluZyBvdXRwdXRTdHJpbmcgPSBTdHJpbmc6OmZyb21V VEY4KG91dHB1dC5nZXQoKSk7Ci0gICAgVmVjdG9yPFN0cmluZz4gbGluZXM7Ci0gICAgb3V0cHV0 U3RyaW5nLnNwbGl0KFVDaGFyKCdcbicpLCAvKiBhbGxvd0VtcHR5RW50cmllcyAqLyBmYWxzZSwg bGluZXMpOwotICAgIGZvciAoc2l6ZV90IGkgPSAwOyBpIDwgbGluZXMuc2l6ZSgpOyArK2kpIHsK LSAgICAgICAgY2hhcioqIGtleVZhbHVlID0gZ19zdHJzcGxpdChsaW5lc1tpXS51dGY4KCkuZGF0 YSgpLCAiPSIsIDIpOwotICAgICAgICBnX2Fzc2VydF9jbXB1aW50KGdfc3Rydl9sZW5ndGgoa2V5 VmFsdWUpLCA9PSwgMik7Ci0gICAgICAgIGlmICghZ19zdHJjbXAwKGtleVZhbHVlWzBdLCAiREJV U19TRVNTSU9OX0JVU19BRERSRVNTIikpIHsKLSAgICAgICAgICAgIG1fYWRkcmVzcyA9IGtleVZh bHVlWzFdOwotICAgICAgICAgICAgZ19zZXRlbnYoIkRCVVNfU0VTU0lPTl9CVVNfQUREUkVTUyIs IGtleVZhbHVlWzFdLCBUUlVFKTsKLSAgICAgICAgfSBlbHNlIGlmICghZ19zdHJjbXAwKGtleVZh bHVlWzBdLCAiREJVU19TRVNTSU9OX0JVU19QSUQiKSkKLSAgICAgICAgICAgIG1fcGlkID0gZ19h c2NpaV9zdHJ0b2xsKGtleVZhbHVlWzFdLCAwLCAxMCk7Ci0gICAgICAgIGdfc3RyZnJlZXYoa2V5 VmFsdWUpOwotICAgIH0KLQotICAgIHJldHVybiBtX3BpZCA+IDA7CisgICAgZ190ZXN0X2RidXNf ZG93bihtX2J1cy5nZXQoKSk7CiB9CiAKLVdlYktpdFRlc3RCdXM6On5XZWJLaXRUZXN0QnVzKCkK K2Jvb2wgV2ViS2l0VGVzdEJ1czo6cnVuKCkKIHsKLSAgICBnX3Vuc2V0ZW52KCJEQlVTX1NFU1NJ T05fQlVTX0FERFJFU1MiKTsKLQotICAgIGlmIChtX3BpZCAhPSAtMSkKLSAgICAgICAga2lsbCht X3BpZCwgU0lHVEVSTSk7CisgICAgQ1N0cmluZyBkaXNwbGF5ID0gZ19nZXRlbnYoIkRJU1BMQVki KTsKKyAgICBnX3Rlc3RfZGJ1c191cChtX2J1cy5nZXQoKSk7CisgICAgbV9hZGRyZXNzID0gZ190 ZXN0X2RidXNfZ2V0X2J1c19hZGRyZXNzKG1fYnVzLmdldCgpKTsKKyAgICBnX3NldGVudigiRElT UExBWSIsIGRpc3BsYXkuZGF0YSgpLCBGQUxTRSk7CisgICAgcmV0dXJuICFtX2FkZHJlc3MuaXNO dWxsKCk7CiB9CiAKIEdEQnVzQ29ubmVjdGlvbiogV2ViS2l0VGVzdEJ1czo6Z2V0T3JDcmVhdGVD b25uZWN0aW9uKCkKQEAgLTc3LDcgKzQ3LDggQEAgR0RCdXNDb25uZWN0aW9uKiBXZWJLaXRUZXN0 QnVzOjpnZXRPckNyZWF0ZUNvbm5lY3Rpb24oKQogICAgIGdfYXNzZXJ0KCFtX2FkZHJlc3MuaXNO dWxsKCkpOwogICAgIG1fY29ubmVjdGlvbiA9IGFkb3B0R1JlZihnX2RidXNfY29ubmVjdGlvbl9u ZXdfZm9yX2FkZHJlc3Nfc3luYyhtX2FkZHJlc3MuZGF0YSgpLAogICAgICAgICBzdGF0aWNfY2Fz dDxHREJ1c0Nvbm5lY3Rpb25GbGFncz4oR19EQlVTX0NPTk5FQ1RJT05fRkxBR1NfQVVUSEVOVElD QVRJT05fQ0xJRU5UIHwgR19EQlVTX0NPTk5FQ1RJT05fRkxBR1NfTUVTU0FHRV9CVVNfQ09OTkVD VElPTiksCi0gICAgICAgIDAsIDAsIDApKTsKKyAgICAgICAgbnVsbHB0ciwgbnVsbHB0ciwgbnVs bHB0cikpOworICAgIGdfYXNzZXJ0KG1fY29ubmVjdGlvbi5nZXQoKSk7CiAgICAgcmV0dXJuIG1f Y29ubmVjdGlvbi5nZXQoKTsKIH0KIApAQCAtODgsMTkgKzU5LDE5IEBAIHN0YXRpYyB2b2lkIG9u TmFtZUFwcGVhcmVkKEdEQnVzQ29ubmVjdGlvbiosIGNvbnN0IGNoYXIqLCBjb25zdCBjaGFyKiwg Z3BvaW50ZXIKIAogR0RCdXNQcm94eSogV2ViS2l0VGVzdEJ1czo6Y3JlYXRlUHJveHkoY29uc3Qg Y2hhciogc2VydmljZU5hbWUsIGNvbnN0IGNoYXIqIG9iamVjdFBhdGgsIGNvbnN0IGNoYXIqIGlu dGVyZmFjZU5hbWUsIEdNYWluTG9vcCogbWFpbkxvb3ApCiB7Ci0gICAgdW5zaWduZWQgd2F0Y2hl cklEID0gZ19idXNfd2F0Y2hfbmFtZV9vbl9jb25uZWN0aW9uKGdldE9yQ3JlYXRlQ29ubmVjdGlv bigpLCBzZXJ2aWNlTmFtZSwgR19CVVNfTkFNRV9XQVRDSEVSX0ZMQUdTX05PTkUsIG9uTmFtZUFw cGVhcmVkLCAwLCBtYWluTG9vcCwgMCk7CisgICAgdW5zaWduZWQgd2F0Y2hlcklEID0gZ19idXNf d2F0Y2hfbmFtZV9vbl9jb25uZWN0aW9uKGdldE9yQ3JlYXRlQ29ubmVjdGlvbigpLCBzZXJ2aWNl TmFtZSwgR19CVVNfTkFNRV9XQVRDSEVSX0ZMQUdTX05PTkUsIG9uTmFtZUFwcGVhcmVkLCBudWxs cHRyLCBtYWluTG9vcCwgbnVsbHB0cik7CiAgICAgZ19tYWluX2xvb3BfcnVuKG1haW5Mb29wKTsK ICAgICBnX2J1c191bndhdGNoX25hbWUod2F0Y2hlcklEKTsKIAogICAgIEdEQnVzUHJveHkqIHBy b3h5ID0gZ19kYnVzX3Byb3h5X25ld19zeW5jKAogICAgICAgICBjb25uZWN0aW9uKCksCiAgICAg ICAgIEdfREJVU19QUk9YWV9GTEFHU19ET19OT1RfQVVUT19TVEFSVCwKLSAgICAgICAgMCwgLy8g R0RCdXNJbnRlcmZhY2VJbmZvCisgICAgICAgIG51bGxwdHIsIC8vIEdEQnVzSW50ZXJmYWNlSW5m bwogICAgICAgICBzZXJ2aWNlTmFtZSwKICAgICAgICAgb2JqZWN0UGF0aCwKICAgICAgICAgaW50 ZXJmYWNlTmFtZSwKLSAgICAgICAgMCwgLy8gR0NhbmNlbGxhYmxlCi0gICAgICAgIDApOworICAg ICAgICBudWxscHRyLCAvLyBHQ2FuY2VsbGFibGUKKyAgICAgICAgbnVsbHB0cik7CiAgICAgZ19h c3NlcnQocHJveHkpOwogICAgIHJldHVybiBwcm94eTsKIH0KZGlmZiAtLWdpdCBhL1Rvb2xzL1Rl c3RXZWJLaXRBUEkvZ3RrL1dlYktpdDJHdGsvV2ViS2l0VGVzdEJ1cy5oIGIvVG9vbHMvVGVzdFdl YktpdEFQSS9ndGsvV2ViS2l0Mkd0ay9XZWJLaXRUZXN0QnVzLmgKaW5kZXggMDNiY2MzYS4uYjhh OGU2MCAxMDA2NDQKLS0tIGEvVG9vbHMvVGVzdFdlYktpdEFQSS9ndGsvV2ViS2l0Mkd0ay9XZWJL aXRUZXN0QnVzLmgKKysrIGIvVG9vbHMvVGVzdFdlYktpdEFQSS9ndGsvV2ViS2l0Mkd0ay9XZWJL aXRUZXN0QnVzLmgKQEAgLTI3LDcgKzI3LDcgQEAKIGNsYXNzIFdlYktpdFRlc3RCdXMgewogcHVi bGljOgogICAgIFdlYktpdFRlc3RCdXMoKTsKLSAgICB2aXJ0dWFsIH5XZWJLaXRUZXN0QnVzKCk7 CisgICAgfldlYktpdFRlc3RCdXMoKTsKIAogICAgIGJvb2wgcnVuKCk7CiAgICAgR0RCdXNQcm94 eSogY3JlYXRlUHJveHkoY29uc3QgY2hhciogc2VydmljZU5hbWUsIGNvbnN0IGNoYXIqIG9iamVj dFBhdGgsIGNvbnN0IGNoYXIqIGludGVyZmFjZU5hbWUsIEdNYWluTG9vcCopOwpAQCAtMzYsNyAr MzYsNyBAQCBwdWJsaWM6CiBwcml2YXRlOgogICAgIEdEQnVzQ29ubmVjdGlvbiogZ2V0T3JDcmVh dGVDb25uZWN0aW9uKCk7CiAKLSAgICBwaWRfdCBtX3BpZDsKKyAgICBHUmVmUHRyPEdUZXN0REJ1 cz4gbV9idXM7CiAgICAgQ1N0cmluZyBtX2FkZHJlc3M7CiAgICAgR1JlZlB0cjxHREJ1c0Nvbm5l Y3Rpb24+IG1fY29ubmVjdGlvbjsKIH07Cg==