From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39413: 26.2; Emacs gets hung Date: Wed, 29 Apr 2020 09:55:57 +0300 Message-ID: <83lfme232a.fsf@gnu.org> References: <85r1ynam0x.fsf@gmail.com> <44e850a0-c8dc-4aec-5706-c52db33697a1@ubin.jp> <119c5df5-080e-c45b-6498-2a2bc0f8273b@yk.rim.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: chiaki.ishikawa@ubin.jp, 39413@debbugs.gnu.org, npostavs@gmail.com To: "ISHIKAWA,chiaki" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 29 08:57:54 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jTgfK-000LQE-Qx for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Apr 2020 08:57:54 +0200 Original-Received: from localhost ([::1]:40852 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTgfJ-0007YL-Q7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Apr 2020 02:57:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44122) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTgf2-0007JV-Vw for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 02:57:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTgeU-0005X5-Hb for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 02:57:36 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58899) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTgeU-0005Ws-4N for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 02:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jTgeU-0002MU-2J for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 02:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 06:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39413 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: unreproducible Original-Received: via spool by 39413-submit@debbugs.gnu.org id=B39413.15881433889034 (code B ref 39413); Wed, 29 Apr 2020 06:57:02 +0000 Original-Received: (at 39413) by debbugs.gnu.org; 29 Apr 2020 06:56:28 +0000 Original-Received: from localhost ([127.0.0.1]:42212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTgdv-0002Ld-Lx for submit@debbugs.gnu.org; Wed, 29 Apr 2020 02:56:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTgdu-0002LS-O4 for 39413@debbugs.gnu.org; Wed, 29 Apr 2020 02:56:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49212) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTgdn-00050Y-CU; Wed, 29 Apr 2020 02:56:19 -0400 Original-Received: from [176.228.60.248] (port=3190 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jTgdj-0000d9-R3; Wed, 29 Apr 2020 02:56:18 -0400 In-Reply-To: <119c5df5-080e-c45b-6498-2a2bc0f8273b@yk.rim.or.jp> (ishikawa@yk.rim.or.jp) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179283 Archived-At: > From: "ISHIKAWA,chiaki" > Date: Wed, 29 Apr 2020 06:36:46 +0900 > Cc: chiaki-ishikawa-thunderbird-account , > Noam Postavsky > > I am back to this strange guru meditation of emacs. > Emacs would eventually begin working, but the silent period where no key > or mouse event is acknowledged is rather longish. > > Several weeks after I installed GNU Emacs 28.0.50 (that is what > |emacs-version| variable says. I installed from git repo.) , I began > noticing the occasional long pause (no response) again. I suggest to begin by establishing whether these pauses are caused by GC. To that end, set garbage-collection-messages to a non-nil value, and see if Emacs displays a message about GC in progress when these pauses occur. Also, try to tell how frequent are these pauses and much time each pause takes. If you see that every time you experience a pause there's GC running, we can then proceed to investigating whether the frequency of GC and the time it takes on your system is something abnormal, and why. > So my take on this is sweep_conses() takes a rather long time and not > letting emacs to take any input. (And there could be other functions > before it.) The question is how long is "long time". We need some quantitative measure of this before we can tell whether it's normal or not. > Question.: Has there been any change in emacs's alloc.c code in the > last year or two? Yes, a lot. But I don't see any significant change in frequency or time duration of GC on my system due to those changes, FWIW. > I am running emacs under Debian GNU/linux inside VirtualBox which is > assigned 16GB memory. It is possible that the virtual machine's memory management is misconfigured, so it slows down Emacs when it needs to access a large portion of its address space (which happens during GC). > gc-elapsed is a variable defined in ‘C source code’. > Its value is 68.3795433 The question is how many GC cycles took 68 seconds. What is the value of gcs-done? Also, is this in a session to which you attached GDB? if so, then some of the elapsed time was due to Emacs being stopped under the debugger. We need these values in a session that is never stopped by a debugger. > PS: Given that this may have something to do with the paging activity > of the emacs process, the linux version change (from 4 to 5) may have > affected the paging behavior of the program, but it is hard to say.  I > now see this linux instance is using 293M SWAP.  Compiling mozilla > thunderbird source runs |make -j6| and g++-9 compiles CPP source files > which are very large and so they exert heavy memory pressure. A bad > memory access pattern of emacs, not friendly to locality of access, > would add to page faults. Except, |xosview| program does not show any > paging activity. I am not sure if |xosview| is correct or not. Building a large program with -j6 also uses CPU, and that could make CPU-intensive operations, such as GC, slow. Was that build running in the same VirtualBox as Emacs? If so, how many physical CPU execution units do you have allocated to VirtualBox?