[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: |
Fri, 06 Sep 2013 11:42:40 +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>
>> Cc: Sebastien Vauban <sva-news@mygooglest.com>, 15156@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...
- bug#15156: 24.3; !MEM FULL!, Sebastien Vauban, 2013/09/05
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/05
- bug#15156: 24.3; !MEM FULL!, Sebastien Vauban, 2013/09/05
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/05
- bug#15156: 24.3; !MEM FULL!, Sebastien Vauban, 2013/09/06
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/06
- bug#15156: 24.3; !MEM FULL!,
Sebastien Vauban <=
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/06
- Message not available
- bug#15156: 24.3; !MEM FULL!, Sebastien Vauban, 2013/09/06
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/06
- Message not available
- bug#15156: 24.3; !MEM FULL!, Sebastien Vauban, 2013/09/17
- bug#15156: 24.3; !MEM FULL!, Eli Zaretskii, 2013/09/17