From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#25279: 26.0.50; Slowdown/crash on certain characters Date: Tue, 27 Dec 2016 21:15:15 +0000 Message-ID: References: <83vau6wi7r.fsf@gnu.org> <83tw9qwh4z.fsf@gnu.org> <83lgv1x2et.fsf@gnu.org> <838tr1wlg4.fsf@gnu.org> <837f6lwkju.fsf@gnu.org> <8360m5wj8z.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1482873379 20287 195.159.176.226 (27 Dec 2016 21:16:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Dec 2016 21:16:19 +0000 (UTC) Cc: 25279@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 27 22:16:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLz6P-00041G-Ht for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 22:16:09 +0100 Original-Received: from localhost ([::1]:56312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLz6U-00070F-1l for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 16:16:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLz6M-0006zy-RD for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 16:16:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLz6I-0005m2-SJ for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 16:16:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41901) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cLz6I-0005ly-P4 for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 16:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cLz6I-0002MW-I5 for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 16:16:02 -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, 27 Dec 2016 21:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25279 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25279-submit@debbugs.gnu.org id=B25279.14828733549063 (code B ref 25279); Tue, 27 Dec 2016 21:16:02 +0000 Original-Received: (at 25279) by debbugs.gnu.org; 27 Dec 2016 21:15:54 +0000 Original-Received: from localhost ([127.0.0.1]:57300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLz69-0002M6-Or for submit@debbugs.gnu.org; Tue, 27 Dec 2016 16:15:54 -0500 Original-Received: from mail-ua0-f174.google.com ([209.85.217.174]:36232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLz67-0002Lt-LR for 25279@debbugs.gnu.org; Tue, 27 Dec 2016 16:15:52 -0500 Original-Received: by mail-ua0-f174.google.com with SMTP id 88so187314475uaq.3 for <25279@debbugs.gnu.org>; Tue, 27 Dec 2016 13:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e8sZtBgvPRFson3CPcLsE6M2Zg/AnGCtKFUAS1VBu4k=; b=SDnjVsNQeCSnvmUDbbtsNFbwRFW6IQNSBx9T8E0Ed7plDvMriycyitnJsDskFHx4bT RqtPK9QcaHp5PRoQfbGt5ckvxVsyFbAYghtdpmSYVbop6qt6z8IohZHIGDEC55Mmv4uj 0vRxdODHY8A0xsZ61z6JS2VXH5a2T0N9UqFl3lIVon5TmhtvwhxQ7EWSeEg8g2nKOtd4 XD0benH3O1IwTUFgibpaPp1aD+kBrWRKn32cqgnbMMmsETstr8EBdt+kINXoSG38PbSb 6rldgKd7k0KTL3BNLG6FE1b44h2Qn+i/0mfGmhK4kdQcN/NUwj35Mkte9Io4IVa4H5eU 0H8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e8sZtBgvPRFson3CPcLsE6M2Zg/AnGCtKFUAS1VBu4k=; b=VPXU6+aoz4U2EpQwel7JbtTEcZtmW+XcTT40i4V7SYLQeXnGYsYstip6Vdij8w3dl4 +uYgU1vCavBmo2aNa6GGXNglRvItmPHgKVGCTXVQDyijzjXrpnQ6IeqsO3jO2cKRtYeD gkvjocA+oXYaqV7IPvk3hkP85ime1cwyCBLv3h9bs1E6f4Fv0RvE04u0iSd7mid8d8A5 ifZ+2eufbnj2Q89EMLal8fT9cYaak9en9oc7gIe8mmiXOpcJXmz8HWgpHnxihU+e5a3B xG8o6fYzEBpEP1C50rrSXxGqn83lpyB4NXmH2On/lUa0Owzld6UcJqDinDrMrUAUqOE9 qEyg== X-Gm-Message-State: AIkVDXJXRk///XOirTdPmb2YJNXpSZJ4UNmke5k0BrGeJIuMBF+hk+bwAPZk7boJ65JkAxGCm8IpSSXg3AazxQ== X-Received: by 10.176.6.231 with SMTP id g94mr25392309uag.91.1482873346050; Tue, 27 Dec 2016 13:15:46 -0800 (PST) Original-Received: by 10.176.71.29 with HTTP; Tue, 27 Dec 2016 13:15:15 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:127506 Archived-At: On 27 December 2016 at 14:32, Richard Copley wrote: > On 27 December 2016 at 14:15, Eli Zaretskii wrote: >>> From: Richard Copley >>> Date: Tue, 27 Dec 2016 14:06:27 +0000 >>> Cc: 25279@debbugs.gnu.org >>> >>> >> But pressing C-g can cause the indefinite hang in SendMessage seen >>> >> above. >>> > >>> > How many threads are in the program when the hang happens? >>> >>> 6, according to an earlier message in this bug. >>> >>> > Is the >>> > input thread still running? It should be stuck in w32_msg_pump or >>> > w32_wnd_proc. >>> >>> Sounds like Thread 3 from that earlier message. >>> >>> Thread 3 (Thread 8808.0x2bfc): >>> #0 0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #1 0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #2 0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #3 0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #4 0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #5 0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #6 0x0000000400216a9b in post_msg () >>> #7 0x00000004001f1920 in post_character_message () >>> #8 0x00000004001fc2b6 in w32_wnd_proc () >>> #9 0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from >>> C:\WINDOWS\System32\user32.dll >>> #10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from >>> C:\WINDOWS\System32\user32.dll >>> #11 0x00000004001f9dc3 in w32_msg_pump.isra () >>> #12 0x00000004001fa430 in w32_msg_worker () >>> #13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from >>> C:\WINDOWS\System32\kernel32.dll >>> #14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from >>> C:\WINDOWS\SYSTEM32\ntdll.dll >>> #15 0x0000000000000000 in ?? () >>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>> >>> > The backtrace you show seems to say that SendMessage doesn't return, >>> > which might mean the thread it is sending the message to is either >>> > dead or not responding. That thread is the input thread. >>> >>> Maybe a deadly embrace then. I'll research how to ask GDB about the >>> state of kernel sync objects. >> >> I think I see what's happening: it's a deadlock. When you type C-g, >> the input thread (which receives all keyboard input from Windows), >> sets the quit-flag, then attempts to send the C-g character to the >> main thread. To send the message, it tries to enter critical section, >> and waits for it. Meanwhile, the main thread tries to tell the input >> thread to draw the scroll bar, and calls SendMessage for that. >> SendMessage waits for the input thread to receive the message, but the >> input thread is stuck waiting for the main thread to exit the critical >> section. > > Great! So we should enter the same critical section in the input thread > before calling SendMessage. > > (I bet it's not that simple. I'm just trying to join in the fun.) For the record: even being charitable and assuming I meant we should enter the critical section in the main thread before telling the input thread to draw the scroll bar, that's stupid and will make Emacs hang on startup, as soon as it first draws the vertical scroll bar. I can reproduce the hang on demand now, with the recipe below, provided Symbola isn't installed, that is, provided MUSIC FLAT SIGN, RIGHTWARDS DOUBLE ARROW or whatever other characters have the property that: > > The fonts Emacs finds for displaying these characters all have > > non-Unicode registry fields, and that causes Emacs to desperately > > look for a Unicode font each time it needs to display one of these > > characters. >From "runemacs -Q": Type "M-x insert-char RET MUSIC SPC FLAT SPC SIGN RET" (or whatever character). Observe that moving point past the character is very slow. In quick succession: 1. Type C-f to move point past the character. 2. Type C-g to signal quit.