GNU bug report logs - #17395
GC during idle time becomes fatal

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17395 in the body.
You can then email your comments to 17395 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Richard Stallman <rms <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: GC during idle time becomes fatal
Date: Sat, 03 May 2014 04:00:38 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I updated from the trunk on May 1, and since then, Emacs seems to GC a
lot when idle.  I am not sure it is GC, but I don't know what else it could be,
and a couple of times Emacs died because I typed C-g at it during that time
and said it was fatal to have an error in GC.

(It is a bug that C-g C-g during GC causes a crash.)

Over time, GC takes longer and longer.  Once I had to kill Emacs
because it went a few minutes without finishing a GC.  A couple of
times, it crashed saying memory was full.

The previously reported problem, applying to epa decryption still
occurs: decryption never finishes.  When I type C-g while it is hung,
I get a message asking me whether to kill the epa process that is
still running.  If I say yes, Emacs responds again but the decryption
has not been done.

I could get more info about that, with some trouble.

I don't know how to give more info about the GC problem.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 17395 <at> debbugs.gnu.org
Subject: Re: bug#17395: GC during idle time becomes fatal
Date: Sat, 03 May 2014 11:23:54 +0300

> Date: Sat, 03 May 2014 04:00:38 -0400
> From: Richard Stallman <rms <at> gnu.org>
> 
> I updated from the trunk on May 1, and since then, Emacs seems to GC a
> lot when idle.  I am not sure it is GC, but I don't know what else it could be,
> and a couple of times Emacs died because I typed C-g at it during that time
> and said it was fatal to have an error in GC.

Please use your ~/.bzr.log to see when was your previous update from
trunk, and to what bzr revision did you update back then.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Richard Stallman <rms <at> gnu.org>
Cc: 17395 <at> debbugs.gnu.org
Subject: Re: bug#17395: GC during idle time becomes fatal
Date: Sun, 04 May 2014 00:00:52 -0400

> (It is a bug that C-g C-g during GC causes a crash.)

Indeed.  And not one I've heard before.

> Over time, GC takes longer and longer.  Once I had to kill Emacs
> because it went a few minutes without finishing a GC.  A couple of
> times, it crashed saying memory was full.

IOW, the problem is not that the GC is taking longer but that the memory
is filling up with many Lisp objects.  You can try M-x profiler-start
RET mem RET ... use Emacs for a while ... M-x profiler-report.
Tho this will only shows us where memory is allocated, which will
contain lots of places where that memory is later correctly reclaimed.
You can also try the install memory-usage (from GNU ELPA) and then M-x
memory-usage RET.  Again, it won't give us very much info, but might
still be helpful.


        Stefan

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

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17395 <at> debbugs.gnu.org
Subject: Re: bug#17395: GC during idle time becomes fatal
Date: Sun, 04 May 2014 00:11:14 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

My previous update was

[14354] 2014-04-24 00:08:25.751 INFO: Updated to revision 117017 of branch bzr+ssh://rms <at> bzr.savannah.gnu.org/emacs/trunk

That is when the decryption bug appeared.  I don't know whether the GC
bug appeared in that version too, because I did not run it for very
long.

before that was

[11166] 2014-04-02 12:56:08.059 INFO: Updated to revision 116929 of branch bzr+ssh://rms <at> bzr.savannah.gnu.org/emacs/trunk

but I did not build it then.  The last version that really worked
was this:

[16633] 2014-03-18 07:22:45.537 INFO: Updated to revision 116791 of branch bzr+ssh://rms <at> bzr.savannah.gnu.org/emacs/trunk

I am sure neither of these bugs was in that version.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17395 <at> debbugs.gnu.org
Subject: Re: bug#17395: GC during idle time becomes fatal
Date: Mon, 05 May 2014 02:59:03 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    IOW, the problem is not that the GC is taking longer but that the memory
    is filling up with many Lisp objects.  You can try M-x profiler-start
    RET mem RET ... use Emacs for a while ... M-x profiler-report.

I have tried this.  I can't understand the answers, though.  I did
profiler-report several times, and each time it displays more than a
meg.  Once it reported over 7 meg.

I did it in a session where I did real work, and got this:

    + redisplay_internal (C function)                          29,776,412   0%
      tooltip-hide                                              8,215,721   0%
    + timer-event-handler                                         336,066   0%
    + compilation-sentinel                                        333,520   0%
    + isearch-pre-command-hook                                    262,144   0%
      internal-timer-start-idle                                   140,161   0%
      undefined                                                   131,072   0%
    + compilation-filter                                           26,200   0%
      clear-transient-map                                           4,120   0%
    + clear-transient-map                                           1,040   0%
    + clear-transient-map                                           1,040   0%
      ...                                                               0   0%
    + command-execute                                          -452333584   0%

But the problem had not happened.

    You can also try the install memory-usage (from GNU ELPA)

How?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17395 <at> debbugs.gnu.org
Subject: Re: bug#17395: GC during idle time becomes fatal
Date: Mon, 05 May 2014 03:00:05 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I can reproduce the frequent and slow GC.  Once decryption fails, and
I quit out of waiting for it, GC becomes quite frequent.

Quitting asks me

  Buffer " *epg*" has a running process; kill it?

I say yes, but afterward there is still a running process called epg.
And each successive decryption attempt creates another process.  I
suppose that is responsible for the frequent garbage collections and
filling up memory.  It seems to GC after every few chars I type, but
not while Emacs is idle.

So the only real bug is the one affecting decryption.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Previous Next

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