GNU bug report logs - #15156
24.3; !MEM FULL!

Previous Next

Packages: w32, emacs;

Reported by: "Sebastien Vauban" <sva-news <at> mygooglest.com>

Date: Wed, 21 Aug 2013 20:28:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15156 <at> debbugs.gnu.org
Subject: Re: bug#15156: 24.3; !MEM FULL!
Date: Fri, 06 Sep 2013 11:42:40 +0200
Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>> Cc: Sebastien Vauban <sva-news <at> mygooglest.com>,  15156 <at> debbugs.gnu.org
>> Date: Fri, 06 Sep 2013 10:55:55 +0200
>> 
>> > All I see in the screencast is that the memory footprint grows, then
>> > shrinks back.  Assuming you have something going on in Emacs that can
>> > explain several hundreds of MBs of memory consumption, that's actually
>> > normal: Emacs uses up memory when it needs it, then releases it when
>> > it no longer does.  So maybe there's no problem here at all.
>> 
>> You take the precaution of "assuming I have something explaining several
>> hundreds of MBs of memory consumption", and that's where the problem lies: I
>> don't have anything that could explain that.
>
> You are using helm, aren't you?

Yes, I do -- can't live without it anymore (to find a file, just type part of
its name, instead of typing every directory from the root). [1]

> That can explain anything at all, as it runs subprocesses on every
> keystroke, AFAIR.

Yes, that's what I remember as well. Though, I wasn't using Helm at the moment
the situation become visible to me; but the full memory could have been
triggered a little while before, and only apparent when I was typing my commit
message.

> Anyway, putting a break at xmalloc conditioned by some large
> allocation size might show who is requesting this much memory.  I
> don't see how this can be investigated otherwise without some
> debugging.

If you have a recipe which does not constrain too much my daily usage of
Emacs, I'm willing to apply it.

>> What's weird as well is that the memory shrinks back to a lower level -- even
>> if still quite important. No apparent reason for that.
>
> GC is normally the reason: Emacs relinquishes memory it doesn't need
> anymore.

OK, clear.

>> And, anyway, I still can't use Emacs as you saw: I'm forced to kill
>> Emacs from the Task Manager.
>
> Why can't you exit Emacs "normally"?  Memory full condition does not
> prevent that.  What happens if you try exiting?

The problem is that Emacs did not respond at all my attempts to get back
control of it. In the video, I typed C-g numerous times in the last minute
(certainly > 10 times). Never got a working state back. My keys simply where
ignored (or not processed yet). I sometimes could type a couple of letters,
but then Emacs went back in his state where it does not listen to my keys
anymore. It really stays completely deaf.

It'd be interesting to get a "key logger" with on-screen display, but I still
did not find one convenient for Windows. That way, you'd see that it simply
stayed unusable.

Another proof of that is that the CPU usage never drops anymore under ~30%
(which seems to be equal to infloop on my i7-3517U CPU, 2 cores, 4 logical
processors).

[1] I'd be interested by knowing what something similar you use...




This bug report was last modified 11 years and 251 days ago.

Previous Next


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