GNU bug report logs - #39413
26.2; Emacs gets hung

Previous Next

Full log

Message #78 received at 39413 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "ISHIKAWA,chiaki" <ishikawa <at> yk.rim.or.jp>
Cc: chiaki.ishikawa <at> ubin.jp, larsi <at> gnus.org, 39413 <at> debbugs.gnu.org,
 npostavs <at> gmail.com
Subject: Re: bug#39413: 26.2; Emacs gets hung
Date: Mon, 16 Aug 2021 14:35:29 +0300

> Cc: larsi <at> gnus.org, npostavs <at> gmail.com, 39413 <at> debbugs.gnu.org,
>  chiaki.ishikawa <at> ubin.jp
> From: "ISHIKAWA,chiaki" <ishikawa <at> yk.rim.or.jp>
> Date: Mon, 16 Aug 2021 08:27:01 +0900
> 
> But if you look slightly above, you will notice CPU core #4 is used 100% 
> (!).
> That is emacs process. No other process is running that earnestly at 
> that moment.

If we believe everything these tools show us, maybe.  But those tools
suffer from the same problem Emacs does on a busy system: the tool
itself might not get CPU to update its data, so you actually see a
snapshot of what it saw last time it did get CPU.

> PS: I found profiler-cpu-* functions, but I don't think it is wise to 
> run them during GC since they seem to allocate vector tables. However, 
> taking a snapshot of strack trace every now and then during GC seems 
> attractive for my investigation to figure out WHERE in GC, the excessive 
> time is spent.

Emacs built-in profiling will not help us here, because it cannot
profile below Lisp primitives.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.