bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15156: 24.3; !MEM FULL!


From: Sebastien Vauban
Subject: bug#15156: 24.3; !MEM FULL!
Date: Thu, 22 Aug 2013 09:16:02 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3 (windows-nt)

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news@mygooglest.com>
>> Date: Wed, 21 Aug 2013 22:26:10 +0200
>> 
>> Quite a couple of times, I've MEM FULL problems with Emacs 24.3.1 under
>> Windows. It begins at no particular time, when editing a buffer.
>> 
>> Emacs begins to take 33% of CPU, fans make noise, and after some time, I've
>> got the following warning:
>> 
>>     Emergency (alloc): Warning: past 95% of memory limit
>
> What is your Emacs's memory footprint at that time?

Private Bytes: 1.6 GB. Working Set: 1.2 GB.

Picture of Process Explorer on http://screencast.com/t/OejSSaeAYSw.

> Also, what does this display:
>
>   M-: (garbage-collect) RET

Picture on http://screencast.com/t/4wi8btwCIiIj (as the output is not written
in the *Messages* buffer).

> And how long was that session up and running, before that happened?
> (You can use the emacs-uptime command to answer the last question.)

15 hours, 14 minutes, 3 seconds

But you must substract the night... So, in fact, something like 6 to 8 hours.

FYI, I restart Emacs at least once every day [1]. Reasons are a.o. that:

- I upgrade Org (and am sure to start in a right config, with no
  defvar/defcustom in the way, if I restart),

- I want to be sure to cleanly save all my files before a crash happen (even
  if we have the M-x recover-this-file, which does not show me what I loose
  and what I gain, I prefer to be sure that files are properly saved),

- I modify things in my .emacs, and want to be sure (before committing) that I
  did not forget a closing paren, or introduced an add-to-list with an unknown
  var)

- etc.

So, I never have Emacs running for more than 12 hours or so.

Best regards,
  Seb

[1] Reason why I'm still interested by having an ultra-fast startup time.

-- 
Sebastien Vauban





reply via email to

[Prev in Thread] Current Thread [Next in Thread]