bug#39413: 26.2; Emacs gets hung

[chiaki-ishikawa-thunderbird-account <chiaki.ishikawa@ubin.jp>]

Hi,

Thank you for your tips.

My comment inline.:

On 2020/04/29 15:55, Eli Zaretskii wrote:
>> From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
>> Date: Wed, 29 Apr 2020 06:36:46 +0900
>> Cc: chiaki-ishikawa-thunderbird-account <chiaki.ishikawa@ubin.jp>,
>>   Noam Postavsky <npostavs@gmail.com>
>>
>> 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.
I have set garbage-collection-messages to t.

Let me see what happens when the next apparent long guru meditation happens.


>> 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.
I agree. It  is all relative.
>> 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.

Maybe I should take a look when my time permits.


>> 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).

I have not touched any thing (famous last words) for my linux 
configuration for the last few years aside from simply upgrading the 
packages from time to time.


>> 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.
>

I will monitor gcs-done when the next guru meditation happens.

Is there a hook to garbage-collection so that I can print gcs-done and 
gc-elapsed maybe after the garbage-collection is run?


>> 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?
>
Yes, the build was running in the same VirtualBox as Emacs.
I have assigned 7 cores to VirtualBox.
(Oh wait!!! My current VirtualBox says it is assigned only 6 cores!?
I thought I did assign 7 cores to this VirtualBox image.
My PC runs Windows 10 natively on AMD Ryzen 7 Eight-Core processor that 
has additional 8 hyperthreads.
So there are 16 virtual cores.
I have no idea why only 6 core is assigned to VM image today.
The number has been tweaked when an earlier VBox had an unresolved issue 
when AMD Ryzen CPU came out.
[I used to run this image on XEON CPU.]
Maybe this could explain the problem on my HOME PC.However, the same 
guru meditation has been observed on office PC with a different Intel 
CPU, too.
Again, Emacs is run inside virtualBox on that PC that runs Windows 10 
professional natively.))

However, the important point is this. I have not noticed this strange 
guru meditation until about 12 months ago or so.
That is why I suspect that there could be an issue with the recent 
alloc.c or something, but I think I need to gather more data
to focus in it yet.

Stay tuned.

Thank you again for your help. I will try to gather more circumstantial 
evidence so that we can make an educated guess why Emacs seems to enter 
guru meditation on my PC.

Chiaki