From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#19868: 25.0.50; Compilation eats buffers Date: Tue, 17 Feb 2015 00:25:41 +0000 Message-ID: References: <83k2zjukmr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a1132e9ca271079050f3dbe37 X-Trace: ger.gmane.org 1424132783 17876 80.91.229.3 (17 Feb 2015 00:26:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 00:26:23 +0000 (UTC) Cc: 19868@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 17 01:26:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNVzS-0006EJ-CZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Feb 2015 01:26:14 +0100 Original-Received: from localhost ([::1]:43241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNVzR-0001l8-OJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Feb 2015 19:26:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNVzN-0001kk-4C for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 19:26:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNVzG-00079w-F8 for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 19:26:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNVzG-00079r-CA for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 19:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YNVzF-0007aa-MD for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 19:26:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Feb 2015 00:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19868 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 19868-submit@debbugs.gnu.org id=B19868.142413275029122 (code B ref 19868); Tue, 17 Feb 2015 00:26:01 +0000 Original-Received: (at 19868) by debbugs.gnu.org; 17 Feb 2015 00:25:50 +0000 Original-Received: from localhost ([127.0.0.1]:45731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNVz3-0007Zb-Ej for submit@debbugs.gnu.org; Mon, 16 Feb 2015 19:25:50 -0500 Original-Received: from mail-yk0-f173.google.com ([209.85.160.173]:41063) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNVz0-0007ZE-U1 for 19868@debbugs.gnu.org; Mon, 16 Feb 2015 19:25:48 -0500 Original-Received: by mail-yk0-f173.google.com with SMTP id 19so14542008ykq.4 for <19868@debbugs.gnu.org>; Mon, 16 Feb 2015 16:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w64/QOwNb4gT3eIgm3RF0MZHJuQb1ir6pDHdgCqmKy0=; b=OwMyHrPyAc/dsPPtExVfprWFp5yaUjPmy56D09VRfQTa5ZYrvw4DxqFTWws/xKmfNX J7wQNnLbM+TPsTPgbO+/ifoqEV/R/AQTUH9SBOQaWz8fk2nvDYG+6ANJ2htPOI2qICYJ WdAUB2GWnaAM1K/5YgkiBILH73aXt4u24xviu5xHqhAJ/IDp88rAXo37XUEySiFeDuyd UHhZ/yFVEgmgiemnW5ihTW32MY+VblFp46z71ecTOl+4BmpD+QZq+eZD/aGfLZ+oYS0v g99IX+ChArAghU72xQ5AmlQ7o9ao4BczT9yfyrw6ehc2pQeMJPYMbWV5TZ0RRBa/U+lD VFhA== X-Received: by 10.236.1.38 with SMTP id 26mr618173yhc.163.1424132741147; Mon, 16 Feb 2015 16:25:41 -0800 (PST) Original-Received: by 10.170.63.135 with HTTP; Mon, 16 Feb 2015 16:25:41 -0800 (PST) In-Reply-To: <83k2zjukmr.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99484 Archived-At: --001a1132e9ca271079050f3dbe37 Content-Type: text/plain; charset=UTF-8 On 15 February 2015 at 17:53, Eli Zaretskii wrote: >> >> On Windows, with MinGW gcc.exe installed and on the path, save a file >> "c:\temp\bug.c" containing these two lines: >> >> #include >> int main () { Sleep (5000); } >> >> Compile with "M-x compile RET", supplying this compile-command: >> gcc -mwindows -o bug.exe bug.c && bug.exe >> >> Within 5 seconds, execute "M-x compile" again and answer "yes" to kill >> the existing process. The process doesn't respond to the signal, > > There are no signals on Windows. Emacs simulates SIGINT and SIGKILL > by other means, see sys_kill. > >> and Emacs hangs inside the call to `delete-process' in >> `compilation-start'. >> >> When the process does eventually die and the `delete-process' call >> returns, the current buffer has changed from *compilation* to the buffer >> from which the compilation was launched (which will often be a source >> code buffer). >> >> `compilation-start' then proceeds to erase the buffer and discard its >> undo history. This is potentially very bad news for the user's source >> code. > > I cannot reproduce this: for me, Emacs doesn't hang at all. As soon > as I answer YES to the kill process question, I see in Process > Explorer that cmdproxy, cmd.exe, and the program that sleeps are all > terminated, and the new compilation begins. Like I'd expect. > > If I instrument the sys_kill function, I see that we first send a > simulated Ctrl-C keystroke to the process, and a second afterwards > terminate it forcefully, which is consistent with the calls to > interrupt-process and delete-process in compilation-start. > > I tried this on Windows 7 and XP, and both show the same correct > behavior. > > It could be that what you see is specific to Windows 8, or to 64-bit > programs, or to how MinGW64 sets up the process in its startup code (I > used MinGW32). I see my problem no matter what compiler I use to build "bug.exe" (old-fashioned MinGW32, and both the 32- and 64-bit MinGW-W64 GCC 4.9.2 toolchains). I'll try on Windows 7, and if I get time, with 32-bit Emacs. when building "bug.exe" with good old MinGW and with both the 32- and 64-bit toolchains from MinGW-W64. I haven't tried it with a 32-bit Emacs. I will try that, and on Windows 7, when I have time. > You say above that Emacs hangs inside the delete-process call -- can > you show a backtrace in that state, preferably from an unoptimized > build? I'd like to see where exactly it hangs. I tried to work out how to control the optimization level when building Emacs but I'm stumped. How do you do that? (If there are configure flags, can they be mentioned in "configure --help"?) FWIW, attached is the result of "thread apply all bt full" after typing Ctrl-C in GDB while debugging an optimized Emacs that was hanging. Looks like I'm doing something horribly wrong. Sorry about that. > Also, is the -mwindows compiler switch a factor here, i.e. does the > problem happen with a console application that sleeps? Yes, -mwindows is needed. Console applications die as expected. > (I'm not sure it should matter, because the process that we are > killing is cmdproxy, not the program you compiled.) Then I don't understand why a GUI program would ever die in response to that. (Would runemacs.exe?) Really I didn't expect it to; that's not the bug I was reporting (though I'm happy to help fix it if it is a bug). > In addition, can you look at the relevant processes in Process > Explorer and seed if any of them are killed when you answer YES? "cmdproxy.exe" and its descendants "cmd.exe" and "conhost.exe" are killed, leaving just the orphaned "bug.exe". >> I'm not sure where the buffer gets changed (presumably in a sentinel, >> but `compilation-sentinel' looks OK to me). > > Run all this under GDB, put a breakpoint on a low-level function that > switches buffers (e.g., in set_buffer_internal), and you will see in > the backtrace which Lisp function triggers that. It is advisable to > manually load compile.el in advance, so that xbacktrace shows more > details. I'm sorry to say that, mysteriously, I can no longer reproduce the effect where the current buffer changes during the `delete-process' call and causes work to be lost. I can't see what I'm doing differently. I might have to get back to you another time. >> In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32) >> of 2015-02-09 on MACHINE >> Repository revision: 21d1f8b85eec8fc1f87bb30398e449f6b20b6ecc >> Windowing system distributor `Microsoft Corp.', version 6.3.9600 >> Configured using: >> `configure --prefix /c/emacs/emacs-20150209-192633 >> --disable-dependency-tracking >> --enable-locallisppath=%emacs_dir%/../site-lisp --with-wide-int >> --build=x86_64-w64-mingw32 'CPPFLAGS=-I G:/usr/include -I >> C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L C:/GnuWin32/lib'' > > Any idea why you are building --with-wide-int? It's supposed to be a > no-op in a 64-bit build. (This is not related to the bug.) I'll remove it, thanks. --001a1132e9ca271079050f3dbe37 Content-Type: text/plain; charset=US-ASCII; name="bt.txt" Content-Disposition: attachment; filename="bt.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i68ho4rl0 UHJvZ3JhbSByZWNlaXZlZCBzaWduYWwgU0lHSU5ULCBJbnRlcnJ1cHQuDQpbU3dpdGNoaW5nIHRv IFRocmVhZCA4NTY4LjB4MTUxOF0NCjB4MDAwMDdmZjljNWNjMzIzMyBpbiBSZWdMb2FkTVVJU3Ry aW5nQSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXHN5c3RlbTMyXEtlcm5lbEJhc2UuZGxsDQooZ2Ri KSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCg0KVGhyZWFkIDcgKFRocmVhZCA4NTY4LjB4MTUx OCk6DQojMCAgMHgwMDAwN2ZmOWM1Y2MzMjMzIGluIFJlZ0xvYWRNVUlTdHJpbmdBICgpDQogICBm cm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcS2VybmVsQmFzZS5kbGwNCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4NCkJhY2t0cmFjZSBzdG9wcGVkOiBwcmV2aW91cyBmcmFtZSBpZGVudGlj YWwgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVhZCA2IChUaHJlYWQgODU2 OC4weDQ1MCk6DQojMCAgMHgwMDAwN2ZmOWM4YWEyOGNhIGluIG50ZGxsIVp3V2FpdEZvcldvcmtW aWFXb3JrZXJGYWN0b3J5ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxs DQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMSAgMHgwMDAwN2ZmOWM4YTQ0ZDI2 IGluIG50ZGxsIVJ0bEZyZWVVbmljb2RlU3RyaW5nICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lT VEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgw MDAwN2ZmOWM4ODIxM2QyIGluIEtFUk5FTDMyIUJhc2VUaHJlYWRJbml0VGh1bmsgKCkNCiAgIGZy b20gQzpcV0lORE9XU1xzeXN0ZW0zMlxrZXJuZWwzMi5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4NCiMzICAweDAwMDA3ZmY5YzhhN2ViNjQgaW4gbnRkbGwhUnRsVXNlclRocmVh ZFN0YXJ0ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojNCAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp DQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJl dmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVh ZCA1IChUaHJlYWQgODU2OC4weDE4MTQpOg0KIzAgIDB4MDAwMDdmZjljOGFhMjhjYSBpbiBudGRs bCFad1dhaXRGb3JXb3JrVmlhV29ya2VyRmFjdG9yeSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZ U1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4 MDAwMDdmZjljOGE0NGQyNiBpbiBudGRsbCFSdGxGcmVlVW5pY29kZVN0cmluZyAoKQ0KICAgZnJv bSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLg0KIzIgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFkSW5p dFRodW5rICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMyAgMHgwMDAwN2ZmOWM4YTdlYjY0IGluIG50 ZGxsIVJ0bFVzZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50 ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzQgIDB4MDAwMDAwMDAw MDAwMDAwMCBpbiA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFja3Ry YWNlIHN0b3BwZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQg c3RhY2s/KQ0KDQpUaHJlYWQgNCAoVGhyZWFkIDg1NjguMHgxOTMwKToNCiMwICAweDAwMDA3ZmY5 YzhhYTBlM2EgaW4gbnRkbGwhWndSZWFkRmlsZSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RF TTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4MDAw MDdmZjljNWMxODNhOCBpbiBSZWFkRmlsZSAoKSBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcS2Vy bmVsQmFzZS5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4NCiMyICAweDAwMDA3 ZmY5Yzg5ODFiNTkgaW4gbXN2Y3J0IV9fY3J0R2V0U3RyaW5nVHlwZVcgKCkNCiAgIGZyb20gQzpc V0lORE9XU1xzeXN0ZW0zMlxtc3ZjcnQuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuDQojMyAgMHgwMDAwN2ZmOWM4OTgxYzc5IGluIG1zdmNydCFfcmVhZCAoKSBmcm9tIEM6XFdJ TkRPV1Ncc3lzdGVtMzJcbXN2Y3J0LmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl Lg0KIzQgIDB4MDAwMDAwMDQwMDE5NjEzNSBpbiBfc3lzX3JlYWRfYWhlYWQgKGZkPTxvcHRpbWl6 ZWQgb3V0PikNCiAgICBhdCBnOi9lbWFjcy9yZXBvL2VtYWNzL3NyYy93MzIuYzo3OTkwDQogICAg ICAgIGNwID0gMHgxMDAwMDAwMDANCiAgICAgICAgcmMgPSAwDQojNSAgMHgwMDAwMDAwNDAwMTli ODE1IGluIHJlYWRlcl90aHJlYWQgKGFyZz0weDQwMTdhNTk0MCA8Y2hpbGRfcHJvY3M+KQ0KICAg IGF0IGc6L2VtYWNzL3JlcG8vZW1hY3Mvc3JjL3czMnByb2MuYzoxMDE3DQogICAgICAgIHJjID0g PG9wdGltaXplZCBvdXQ+DQogICAgICAgIGNwID0gMHg0MDE3YTU5NDAgPGNoaWxkX3Byb2NzPg0K IzYgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFkSW5pdFRodW5rICgp DQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuDQojNyAgMHgwMDAwN2ZmOWM4YTdlYjY0IGluIG50ZGxsIVJ0bFVz ZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0K Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzggIDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFja3RyYWNlIHN0b3Bw ZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQ0K DQpUaHJlYWQgMyAoVGhyZWFkIDg1NjguMHgyMjU4KToNCiMwICAweDAwMDA3ZmY5YzYwNzI2Y2Eg aW4gVVNFUjMyIUdldE1lc3NhZ2VXICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcdXNl cjMyLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4MDAwMDdmZjlj NjA3MjY5NSBpbiBVU0VSMzIhR2V0TWVzc2FnZVcgKCkNCiAgIGZyb20gQzpcV0lORE9XU1xzeXN0 ZW0zMlx1c2VyMzIuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgw MDAwMDAwNDAwMTcwMDY4IGluIHczMl9tc2dfcHVtcCAobXNnX2J1Zj0weDJlY2ZlZjApDQogICAg YXQgZzovZW1hY3MvcmVwby9lbWFjcy9zcmMvdzMyZm5zLmM6MjUyNg0KICAgICAgICBtc2cgPSB7 aHduZCA9IDB4MTkwNmQwLCBtZXNzYWdlID0gMjc1LCB3UGFyYW0gPSAxLCBsUGFyYW0gPSAwLA0K ICAgICAgICAgIHRpbWUgPSA0NTIyOTAwOTMsIHB0ID0ge3ggPSAyNzMsIHkgPSAxMDc1fX0NCiAg ICAgICAgZm9jdXNfd2luZG93ID0gPG9wdGltaXplZCBvdXQ+DQojMyAgMHgwMDAwMDAwNDAwMTcw NWMwIGluIHczMl9tc2dfd29ya2VyIChhcmc9PG9wdGltaXplZCBvdXQ+KQ0KLS0tVHlwZSA8cmV0 dXJuPiB0byBjb250aW51ZSwgb3IgcSA8cmV0dXJuPiB0byBxdWl0LS0tDQogICAgYXQgZzovZW1h Y3MvcmVwby9lbWFjcy9zcmMvdzMyZm5zLmM6Mjc0Nw0KICAgICAgICBtc2cgPSB7aHduZCA9IDB4 MCwgbWVzc2FnZSA9IDAsIHdQYXJhbSA9IDAsIGxQYXJhbSA9IDAsIHRpbWUgPSAwLA0KICAgICAg ICAgIHB0ID0ge3ggPSAwLCB5ID0gMH19DQogICAgICAgIGR1bW15X2J1ZiA9IHtuZXh0ID0gMHgw LCB3MzJtc2cgPSB7bXNnID0ge2h3bmQgPSAweDAsIG1lc3NhZ2UgPSAwLA0KICAgICAgICAgICAg ICB3UGFyYW0gPSAwLCBsUGFyYW0gPSAwLCB0aW1lID0gMCwgcHQgPSB7eCA9IDAsIHkgPSAwfX0s DQogICAgICAgICAgICBkd01vZGlmaWVycyA9IDAsIHJlY3QgPSB7bGVmdCA9IDAsIHRvcCA9IDAs IHJpZ2h0ID0gMCwNCiAgICAgICAgICAgICAgYm90dG9tID0gMH19LCByZXN1bHQgPSAwLCBjb21w bGV0ZWQgPSAwfQ0KIzQgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFk SW5pdFRodW5rICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojNSAgMHgwMDAwN2ZmOWM4YTdlYjY0IGlu IG50ZGxsIVJ0bFVzZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMy XG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzYgIDB4MDAwMDAw MDAwMDAwMDAwMCBpbiA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFj a3RyYWNlIHN0b3BwZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1 cHQgc3RhY2s/KQ0KDQpUaHJlYWQgMiAoVGhyZWFkIDg1NjguMHgxNWE0KToNCiMwICAweDAwMDA3 ZmY5YzhhYTExMWEgaW4gbnRkbGwhWndEZWxheUV4ZWN1dGlvbiAoKQ0KICAgZnJvbSBDOlxXSU5E T1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0K IzEgIDB4MDAwMDdmZjljNWMxMTIxYSBpbiBTbGVlcEV4ICgpIGZyb20gQzpcV0lORE9XU1xzeXN0 ZW0zMlxLZXJuZWxCYXNlLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzIg IDB4MDAwMDAwMDQwMDE5YmRhYiBpbiB0aW1lcl9sb29wIChhcmc9MHgwKQ0KICAgIGF0IGc6L2Vt YWNzL3JlcG8vZW1hY3Mvc3JjL3czMnByb2MuYzozODENCiAgICAgICAgc2xlZXBfdGltZSA9IDxv cHRpbWl6ZWQgb3V0Pg0KICAgICAgICBoYW5kbGVyID0gPG9wdGltaXplZCBvdXQ+DQogICAgICAg IG5vdyA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBleHBpcmUgPSA8b3B0aW1pemVkIG91dD4N CiAgICAgICAgcmVsb2FkID0gPG9wdGltaXplZCBvdXQ+DQogICAgICAgIGl0aW1lciA9IDB4MA0K ICAgICAgICB3aGljaCA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBzaWcgPSA8b3B0aW1pemVk IG91dD4NCiAgICAgICAgY3JpdCA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBtYXhfc2xlZXAg PSA8b3B0aW1pemVkIG91dD4NCiAgICAgICAgaHRoID0gMHgwDQojMyAgMHgwMDAwN2ZmOWM4ODIx M2QyIGluIEtFUk5FTDMyIUJhc2VUaHJlYWRJbml0VGh1bmsgKCkNCiAgIGZyb20gQzpcV0lORE9X U1xzeXN0ZW0zMlxrZXJuZWwzMi5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4N CiM0ICAweDAwMDA3ZmY5YzhhN2ViNjQgaW4gbnRkbGwhUnRsVXNlclRocmVhZFN0YXJ0ICgpDQog ICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuDQojNSAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJldmlvdXMgZnJhbWUg aW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVhZCAxIChUaHJlYWQg ODU2OC4weDEwYzgpOg0KIzAgIDB4MDAwMDdmZjljOGFhMGUxYSBpbiBudGRsbCFad1dhaXRGb3JT aW5nbGVPYmplY3QgKCkNCiAgIGZyb20gQzpcV0lORE9XU1xTWVNURU0zMlxudGRsbC5kbGwNCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4NCiMxICAweDAwMDA3ZmY5YzhhNDlhODUgaW4g bnRkbGwhUnRsSW1hZ2VOdEhlYWRlckV4ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJc bnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgwMDAwN2Zm OWM4YTQ3ZjQ0IGluIG50ZGxsIVJ0bEVudGVyQ3JpdGljYWxTZWN0aW9uICgpDQogICBmcm9tIEM6 XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJldmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFt ZSAoY29ycnVwdCBzdGFjaz8pDQooZ2RiKQ0K --001a1132e9ca271079050f3dbe37--