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

Previous Next

Full log

View this message in rfc822 format

From: chiaki-ishikawa-thunderbird-account <chiaki.ishikawa <at> ubin.jp>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: chiaki-ishikawa-thunderbird-account <chiaki.ishikawa <at> ubin.jp>, Eli Zaretskii <eliz <at> gnu.org>, 39413 <at> debbugs.gnu.org
Subject: bug#39413: 26.2; Emacs gets hung
Date: Tue, 26 May 2020 00:50:15 +0900

On 2020/05/25 21:15, Noam Postavsky wrote:
> chiaki-ishikawa-thunderbird-account <chiaki.ishikawa <at> ubin.jp> writes:
>
>> Short of lisp function, maybe I can add message print out in alloc.c
>> to print out such information so that it gets recorded in *Message*
>> buffer.
>> It is done only when gabage-collection-message is t and there should
>> be some throttling mechanism to avoid spamming the user.
>> Any pointer re the hook(s) short of rewriting alloc.c is
>> appreciated. Well, if worst comes to worst, I don't mind rewriting
>> alloc.c to create an array of fixed size to store the last dozen or so
>> GC-related information that is updated before and after invocation of
>> a certain GC entry point.
>> I can print that out after a long GC to learn the memory situation.
>> But that sounds a bit drastic. OTOH, it may be the only way to go.
> That should probably work.  I see the current
> garbage_collection_messages code uses message_nolog, I guess because
> growing the *Messages* buffer could also trigger GC.
>
Thank you, I will probably do that.

Back in 18.x days, printing the message from within GC caused another GC 
invocation, thus emacs blew up due to stack flow after so many recursive 
calls.

I think having a static array of 10-20 cells to store previous GC info 
should work.

Stay tuned. I am really interested in WHERE/WHY this long pause occurs.: 
maybe Windows 10 memory allocation/ Virtual Box emulation/Linux kernel 
memory allocation, and AMD Ryzen CPU's cache replacement policy all add up.

Chiaki

Previous Next

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