GNU bug report logs - #37006
27.0.50; garbage collection not happening after 26de2d42

Previous Next

Package: emacs;

Reported by: Joseph Mingrone <jrm <at> ftfl.ca>

Date: Sun, 11 Aug 2019 12:41:01 UTC

Severity: normal

Tags: patch

Found in version 27.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Joseph Mingrone <jrm <at> ftfl.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, eggert <at> cs.ucla.edu, 37006 <at> debbugs.gnu.org
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
Date: Mon, 12 Aug 2019 11:34:18 -0300
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Joseph Mingrone <jrm <at> ftfl.ca>
>> Cc: Mattias EngdegÄrd <mattiase <at> acm.org>,
>>   eggert <at> cs.ucla.edu
>> Date: Sun, 11 Aug 2019 17:28:11 -0300

>> > Thanks, I fixed this slightly differently, in a way that makes it more
>> > explicit why we need a non-trivial code there.  Joseph, please see if
>> > the latest master fixes the problem.

>> > (IMNSHO, this issue makes INT_ADD_WRAPV and friends unsafe; at the
>> > very least this caveat should be prominently documented in Gnulib's
>> > intprops.h.)

>> I have been running 94644d8 for the past hour or so and resident
>> memory for the Emacs process is up over 1300 MB.  Also with
>> `garbage-collection-messages' set to t, I do not see any messages
>> about garbage collection.

> Are you saying that the fix didn't solve the problem for you?  I
> definitely saw a lot of GC messages after the fix where I didn't
> before.  For example, if you visit xdisp.c from the Emacs sources and
> page through it with C-v, don't you see a lot of GC messages?

>> I should also add that after my initial report, running 26de2d42, I
>> did eventually start seeing garbage collection messages and the
>> memory usage stopped increasing.  Something must have triggered
>> garbage collection to start again.

> After a lot of consing, the GC would come back for a while, until it
> would be effectively disabled again by some opportune code path.

> If you see no GC messages for a long time, attach a debugger and look
> at the value of consing_until_gc.  If its value is huge, around
> LONG_MAX, the problem is still not completely solved.

The fix did not initially work for me.  I tested a bit more.  With

1. emacs -Q
2. (setq garbage-collection-messages t)
3. page through xdisp.c

I saw lots of garbage collection messages.  But, with my init.el there
were no such messages.  My init.el looked like this.

----------------------------------------------------
(setq gc-cons-threshold most-positive-fixnum)

;; contents of init.el here

(setq gc-cons-threshold 800000) ;; default value
----------------------------------------------------

When I removed the surrounding setqs, garbage collection message were
shown again when paging through xdisp.c.

I assume that temporarily setting `gc-cons-threshold' to a large number
to temporarily prevent garbage collection, then setting it back to a
reasonable value should be acceptable.  Help for `gc-cons-threshold'
says

      By binding this temporarily to a large number, you can effectively
      prevent garbage collection during a part of the program.

--
Joseph
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 5 years and 246 days ago.

Previous Next


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