From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Sebastien Vauban" Newsgroups: gmane.emacs.bugs Subject: bug#15156: 24.3; !MEM FULL! Date: Fri, 06 Sep 2013 11:42:40 +0200 Organization: Sebastien Vauban Message-ID: <86a9jqs2un.fsf@somewhere.org> References: <8638q2iye5.fsf@somewhere.org> <52170AC5.1070109@gmx.at> <86ppt4nj2l.fsf@somewhere.org> <8661uf2yl6.fsf@somewhere.org> <83sixjbb6x.fsf@gnu.org> <86wqmv1h0b.fsf@somewhere.org> <83ob87b9yy.fsf@gnu.org> <86eh92s50k.fsf@somewhere.org> <83ioyemhl4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1378460654 13387 80.91.229.3 (6 Sep 2013 09:44:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Sep 2013 09:44:14 +0000 (UTC) Cc: 15156-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Fri Sep 06 11:44:16 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VHsaN-0001VU-L7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Sep 2013 11:44:15 +0200 Original-Received: from localhost ([::1]:36222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHsaN-0000ak-Ae for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Sep 2013 05:44:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHsaF-0000aT-M1 for bug-gnu-emacs-mXXj517/zsQ@public.gmane.org; Fri, 06 Sep 2013 05:44:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHsaB-0000fC-3x for bug-gnu-emacs-mXXj517/zsQ@public.gmane.org; Fri, 06 Sep 2013 05:44:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHsaB-0000f7-0d for bug-gnu-emacs-mXXj517/zsQ@public.gmane.org; Fri, 06 Sep 2013 05:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VHsaA-0007JU-HM for bug-gnu-emacs-mXXj517/zsQ@public.gmane.org; Fri, 06 Sep 2013 05:44:02 -0400 X-Loop: help-debbugs-mXXj517/zsQ@public.gmane.org Resent-From: "Sebastien Vauban" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs-mXXj517/zsQ@public.gmane.org Resent-Date: Fri, 06 Sep 2013 09:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs-mXXj517/zsQ@public.gmane.org X-GNU-PR-Message: followup 15156 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 15156-submit-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org id=B15156.137846058328023 (code B ref 15156); Fri, 06 Sep 2013 09:44:02 +0000 Original-Received: (at 15156) by debbugs.gnu.org; 6 Sep 2013 09:43:03 +0000 Original-Received: from localhost ([127.0.0.1]:43133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VHsZD-0007Hv-1I for submit-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org; Fri, 06 Sep 2013 05:43:03 -0400 Original-Received: from dd5e0353a.access.telenet.be ([213.224.53.58]:25091 helo=mail.missioncriticalit.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VHsZA-0007HN-Fw for 15156-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org; Fri, 06 Sep 2013 05:43:01 -0400 Original-Received: from MUNDANEUM. (unknown [10.10.10.51]) by mail.missioncriticalit.com (Postfix) with ESMTPS id B6553500DB8; Fri, 6 Sep 2013 11:42:52 +0200 (CEST) X-Url: Under construction... X-Archive: encrypt In-Reply-To: <83ioyemhl4.fsf-mXXj517/zsQ@public.gmane.org> (Eli Zaretskii's message of "Fri, 06 Sep 2013 12:20:55 +0300") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3 (windows-nt) X-BeenThere: debbugs-submit-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs-mXXj517/zsQ@public.gmane.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.emacs.bugs:78040 Archived-At: Eli Zaretskii wrote: >> From: "Sebastien Vauban" >> Cc: Sebastien Vauban , 15156-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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...