* memory leaks
@ 2019-09-20 7:23 Madhu
2019-09-20 8:00 ` Jean-Christophe Helary
2019-09-20 8:11 ` Eli Zaretskii
0 siblings, 2 replies; 44+ messages in thread
From: Madhu @ 2019-09-20 7:23 UTC (permalink / raw)
To: help-gnu-emacs
There is obviously some memory leak in emacs and I don't know how to
trace the culprit. Emacs lops up 2GB RSS: ps axuw |grep emacs
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
madhu 5434 6.9 54.2 2235612 2115564 ? SNsl Sep19 66:42 emacs --daemon --debug-init
(garbage-collect) shows
((conses 16 981544 136697)
(symbols 48 56864 5)
(strings 32 312273 12669)
(string-bytes 1 18002558)
(vectors 16 68285)
(vector-slots 8 1780950 150102)
(floats 8 1089 2405)
(intervals 56 6605 2469)
(buffers 992 79))
So does this look like a X fonts issue? How can I figure out which
package is the culprit.
1. Emacs has a bug where I can't look at /proc/5434/emacs from within
emacs it will only read 16384 bytes from the proc filesystem
2. Trying to Unload a feature hits all sorts of design and
implementation bugs with the cl-generics scourge which is unfortunately
used to implement emacs. Is unloading features likely to help at all in
reducing the memory and getting a clue about the errant package?
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: memory leaks
2019-09-20 7:23 memory leaks Madhu
@ 2019-09-20 8:00 ` Jean-Christophe Helary
2019-09-20 8:11 ` Eli Zaretskii
1 sibling, 0 replies; 44+ messages in thread
From: Jean-Christophe Helary @ 2019-09-20 8:00 UTC (permalink / raw)
To: Help Gnu Emacs mailing list
I had something similar happening the other day and Eli told me it was probably fixed with some code recently committed to master. Have you tried a recent build ?
Jean-Christophe Helary
> On Sep 20, 2019, at 16:23, Madhu <enometh@meer.net> wrote:
>
>
> There is obviously some memory leak in emacs and I don't know how to
> trace the culprit. Emacs lops up 2GB RSS: ps axuw |grep emacs
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> madhu 5434 6.9 54.2 2235612 2115564 ? SNsl Sep19 66:42 emacs --daemon --debug-init
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: memory leaks
2019-09-20 7:23 memory leaks Madhu
2019-09-20 8:00 ` Jean-Christophe Helary
@ 2019-09-20 8:11 ` Eli Zaretskii
[not found] ` <mailman.572.1568967069.2190.help-gnu-emacs@gnu.org>
1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-20 8:11 UTC (permalink / raw)
To: help-gnu-emacs
> From: Madhu <enometh@meer.net>
> Date: Fri, 20 Sep 2019 12:53:46 +0530
>
>
> There is obviously some memory leak in emacs and I don't know how to
> trace the culprit. Emacs lops up 2GB RSS: ps axuw |grep emacs
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> madhu 5434 6.9 54.2 2235612 2115564 ? SNsl Sep19 66:42 emacs --daemon --debug-init
Which version of Emacs? If this is a development snapshot, when was
it built?
> 1. Emacs has a bug where I can't look at /proc/5434/emacs from within
> emacs it will only read 16384 bytes from the proc filesystem
Please report as a bug using "M-x report-emacs-bug".
> 2. Trying to Unload a feature hits all sorts of design and
> implementation bugs with the cl-generics scourge which is unfortunately
> used to implement emacs. Is unloading features likely to help at all in
> reducing the memory and getting a clue about the errant package?
Likewise.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: memory leaks
@ 2020-11-10 1:24 Madhu
2020-11-10 15:16 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Madhu @ 2020-11-10 1:24 UTC (permalink / raw)
To: help-gnu-emacs; +Cc: 43395
[Test case follows. Sorry Drew for trying to post to help-gnu and
debbugs simultaneously, but this is my third attempt at sending this
test case - I've tried sending it to debbugs.gnu.org and to
gmane.emacs.help newsgroup - and my messages have been dropped]
* Madhu <m35z8gise6.fsf@leonis4.robolove.meer.net> :
Wrote on Mon, 14 Sep 2020 15:36:57 +0530:
> The numbers I reported by garbage-collect do not account for the memory
> usage. FWIW I've posted that info again at
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43395
I found test case for this bug and I sent mail to 43395@debbugs.gnu.org,
and qmail told me that the mail was accepted:
delivery 1: success:
209.51.188.43_accepted_message./Remote_host_said:_250_OK_id=1kc8Bf-00061T-3u/
But the bugreport didn't show up on gnu.emacs.bug.
Here is the test case:
#+BEGIN_SRC
$ cat > f.c
#include <stdio.h>
int
main()
{
char c = ' ';
while (c != 'q' && c != 'Q')
{
fprintf(stdout, "Press q then enter to quit: ");
c = fgetc(stdin);
}
return 0;
}
^D
$ gcc f.c
$ emacs -Q
#+END_SRC
M-x shell-command ./a.out
Then the process hangs. But Emacs' memory grows unbounded.
WARNING. Be careful to interrupt it with ^G before the OOM killer
kicks in. If you have swap you may lose control of your machine
indefinitely.
After you interrupt the sub process, Emacs is left with unreclaimed
gigabytes of RSS
Please let me know if you can reproduce this
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: memory leaks
2020-11-10 1:24 Madhu
@ 2020-11-10 15:16 ` Eli Zaretskii
0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2020-11-10 15:16 UTC (permalink / raw)
To: help-gnu-emacs
> From: Madhu <enometh@meer.net>
> Date: Tue, 10 Nov 2020 06:54:56 +0530
> Cc: 43395@debbugs.gnu.org
>
> #+BEGIN_SRC
> $ cat > f.c
> #include <stdio.h>
> int
> main()
> {
> char c = ' ';
> while (c != 'q' && c != 'Q')
> {
> fprintf(stdout, "Press q then enter to quit: ");
> c = fgetc(stdin);
> }
> return 0;
> }
> ^D
>
> $ gcc f.c
> $ emacs -Q
> #+END_SRC
>
> M-x shell-command ./a.out
>
> Then the process hangs. But Emacs' memory grows unbounded.
Short answer: you use a command that cannot handle this case. For the
details, please refer to the bug tracker.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Memory leaks
@ 2011-03-03 17:13 Uday S Reddy
2011-03-03 17:55 ` Andreas Schwab
0 siblings, 1 reply; 44+ messages in thread
From: Uday S Reddy @ 2011-03-03 17:13 UTC (permalink / raw)
To: emacs-devel
I am trying to track down some possible memory leaks in VM. I have been
assuming that, when a buffer gets killed,
- all its string memory is reclaimed,
- all the buffer-local variables are reclaimed, and
- all the overlays and intervals are reclaimed.
Are any of these assumptions invalid? If so, what can I do about the
lost memory?
Cheers,
Uday
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-03 17:13 Memory leaks Uday S Reddy
@ 2011-03-03 17:55 ` Andreas Schwab
2011-03-03 18:00 ` Uday S Reddy
0 siblings, 1 reply; 44+ messages in thread
From: Andreas Schwab @ 2011-03-03 17:55 UTC (permalink / raw)
To: Uday S Reddy; +Cc: emacs-devel
Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> I am trying to track down some possible memory leaks in VM. I have been
> assuming that, when a buffer gets killed,
>
> - all its string memory is reclaimed,
>
> - all the buffer-local variables are reclaimed, and
>
> - all the overlays and intervals are reclaimed.
>
> Are any of these assumptions invalid? If so, what can I do about the lost
> memory?
In general no memory is reclaimed until the next garbage collection (but
the buffer text is freed immediately).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-03 17:55 ` Andreas Schwab
@ 2011-03-03 18:00 ` Uday S Reddy
2011-03-03 23:40 ` Andreas Schwab
0 siblings, 1 reply; 44+ messages in thread
From: Uday S Reddy @ 2011-03-03 18:00 UTC (permalink / raw)
To: emacs-devel
On 3/3/2011 5:55 PM, Andreas Schwab wrote:
> In general no memory is reclaimed until the next garbage collection (but
> the buffer text is freed immediately).
Yes, of course. I guess they become "reclaimable" after a buffer is killed.
So, if I have memory leaking, it would seem that the only possibility is
from global variables?
Cheers,
Uday
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-03 18:00 ` Uday S Reddy
@ 2011-03-03 23:40 ` Andreas Schwab
2011-03-04 11:39 ` Uday S Reddy
0 siblings, 1 reply; 44+ messages in thread
From: Andreas Schwab @ 2011-03-03 23:40 UTC (permalink / raw)
To: Uday S Reddy; +Cc: emacs-devel
Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> So, if I have memory leaking, it would seem that the only possibility is
> from global variables?
How do you know that there is some leak?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-03 23:40 ` Andreas Schwab
@ 2011-03-04 11:39 ` Uday S Reddy
2011-03-04 12:19 ` Eli Zaretskii
2011-03-07 19:19 ` Uday S Reddy
0 siblings, 2 replies; 44+ messages in thread
From: Uday S Reddy @ 2011-03-04 11:39 UTC (permalink / raw)
To: emacs-devel; +Cc: u.s.reddy
On 3/3/2011 11:40 PM, Andreas Schwab wrote:
> How do you know that there is some leak?
First there was a suspicion, and now I have been running experiments.
Here are the profiles returned by (garbage-collect), pretty-printed, for
the same Emacs session over time. In each case, the Emacs session was
essentially empty, with just a few stray text buffers . The difference
is only in what happened in between.
Initial:
(:conses (102590 . 13880)
:syms (20328 . 54)
:miscs (830 . 152)
:chars 570345 :vector 329747 :floats (72 . 111)
:intervals (348 . 189)
:strings (21259 . 5705))
After one visit to my INBOX folder (22MB) and quitting:
(:conses (663630 . 605600)
:syms (32257 . 2608)
:miscs (15443 . 18022)
:chars 1639236 :vector 454670 :floats (345 . 261)
:intervals (503 . 622)
:strings (99122 . 90256))
After a second visit to the same folder and quitting:
(:conses (1113362 . 334402)
:syms (32264 . 2807)
:miscs (15467 . 36265)
:chars 1833568 :vector 456351 :floats (345 . 328)
:intervals (604 . 849)
:strings (138140 . 122806))
After several hours of usage:
(:conses (1558351 . 313757)
:syms (93011 . 347)
:miscs (140492 . 28025)
:chars 9264181 :vector 2283330 :floats (347 . 638)
:intervals (2771 . 4880)
:strings (467731 . 34316))
At this point, the total memory occupied was about 400MB, and Emacs
complained that "memory was exhausted; save buffers and quit" (or
something to that effect). I ran garbage-collect, killed all the stray
buffers and left it around for a while (about 10-15 minutes), and the
memory came down to 340MB. (The memory usage figures are from the
Windows XP Task Manger - "VM Size" - VM here referring to the virtual
memory.)
After that, I could do a couple of more folder visits and then Emacs
crashed in the middle of a folder visit. Come to think of it, almost
all the Emacs crashes I have experienced over the last year or so were
probably related to the memory leak problem. They all happened when I
was visiting a folder.
Recalling from my memory, these kind of crashes have started happening
with Emacs 22.3. There were no such crashes before then. I stuck to
Emacs 22.2 for a long time, hoping that whatever was causing the crashes
would get fixed in due course. But with every new release, the same
kind of crashes appeared.
Here is a crash report from yesterday produced by DrMinGW.
Unfortunately, I was in the middle of a Lisp debugger session and the
crash happened while the debugger was trying print a large data
structure. But this does look like a memory problem to my untrained eye.
Cheers,
Uday
---------------
emacs.exe caused an Access Violation at location 77c47412 in module
msvcrt.dll Writing to location 18874000.
Registers:
eax=00829240 ebx=02bb2802 ecx=00000000 edx=00000001 esi=008292bf
edi=18874000
eip=77c47412 esp=00829290 ebp=00829298 iopl=0 nv up ei ng nz ac
pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000293
Call stack:
77C47412 msvcrt.dll:77C47412 memmove
0110AD0F emacs.exe:0110AD0F printchar print.c:323
0110FC03 emacs.exe:0110FC03 print_object print.c:1645
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0111148E emacs.exe:0111148E print_object print.c:2215
0111148E emacs.exe:0111148E print_object print.c:2215
011105A3 emacs.exe:011105A3 print_object print.c:1921
0110EAE2 emacs.exe:0110EAE2 print print.c:1305
0110CF92 emacs.exe:0110CF92 Fprin1 print.c:751
01022B04 emacs.exe:01022B04 Ffuncall eval.c:3034
01114C11 emacs.exe:01114C11 Fbyte_code bytecode.c:680
010232C3 emacs.exe:010232C3 funcall_lambda eval.c:3220
01022D03 emacs.exe:01022D03 Ffuncall eval.c:3077
01114C11 emacs.exe:01114C11 Fbyte_code bytecode.c:680
01021B46 emacs.exe:01021B46 Feval eval.c:2356
0101ED68 emacs.exe:0101ED68 Fprogn eval.c:415
01102A41 emacs.exe:01102A41 Fsave_window_excursion window.c:6575
0111579A emacs.exe:0111579A Fbyte_code bytecode.c:841
010232C3 emacs.exe:010232C3 funcall_lambda eval.c:3220
01022D03 emacs.exe:01022D03 Ffuncall eval.c:3077
010221D6 emacs.exe:010221D6 Fapply eval.c:2506
010225FD emacs.exe:010225FD apply1 eval.c:2780
0101EB72 emacs.exe:0101EB72 call_debugger eval.c:272
01022E12 emacs.exe:01022E12 Ffuncall eval.c:3102
01114C11 emacs.exe:01114C11 Fbyte_code bytecode.c:680
01021B46 emacs.exe:01021B46 Feval eval.c:2356
01020165 emacs.exe:01020165 internal_catch eval.c:1228
0111580E emacs.exe:0111580E Fbyte_code bytecode.c:855
010232C3 emacs.exe:010232C3 funcall_lambda eval.c:3220
01022D03 emacs.exe:01022D03 Ffuncall eval.c:3077
010221D6 emacs.exe:010221D6 Fapply eval.c:2506
010225FD emacs.exe:010225FD apply1 eval.c:2780
01117B84 emacs.exe:01117B84 Fcall_interactively callint.c:396
01022B2E emacs.exe:01022B2E Ffuncall eval.c:3037
010226CC emacs.exe:010226CC call3 eval.c:2857
01014D52 emacs.exe:01014D52 Fcommand_execute keyboard.c:10562
010150C3 emacs.exe:010150C3 Fexecute_extended_command keyboard.c:10675
01022AE3 emacs.exe:01022AE3 Ffuncall eval.c:3031
0111932A emacs.exe:0111932A Fcall_interactively callint.c:869
01022B2E emacs.exe:01022B2E Ffuncall eval.c:3037
010226CC emacs.exe:010226CC call3 eval.c:2857
01014D52 emacs.exe:01014D52 Fcommand_execute keyboard.c:10562
010076E0 emacs.exe:010076E0 command_loop_1 keyboard.c:1914
01020614 emacs.exe:01020614 internal_condition_case eval.c:1492
01005FE3 emacs.exe:01005FE3 command_loop_2 keyboard.c:1362
01020165 emacs.exe:01020165 internal_catch eval.c:1228
01005F9C emacs.exe:01005F9C command_loop keyboard.c:1342
0100588E emacs.exe:0100588E recursive_edit_1 keyboard.c:956
010059F7 emacs.exe:010059F7 Frecursive_edit keyboard.c:1019
010028F5 emacs.exe:010028F5 main emacs.c:1835
010010DB emacs.exe:010010DB
01001178 emacs.exe:01001178
010036D0 emacs.exe:010036D0 _start unexw32.c:131
7C817077 kernel32.dll:7C817077 RegisterWaitForInputIdle
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-04 11:39 ` Uday S Reddy
@ 2011-03-04 12:19 ` Eli Zaretskii
2011-03-04 12:59 ` Uday S Reddy
2011-03-07 19:19 ` Uday S Reddy
1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2011-03-04 12:19 UTC (permalink / raw)
To: Uday S Reddy; +Cc: emacs-devel
> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Date: Fri, 04 Mar 2011 11:39:05 +0000
> Cc: u.s.reddy@cs.bham.ac.uk
>
> Initial:
>
> (:conses (102590 . 13880)
> :syms (20328 . 54)
> :miscs (830 . 152)
> :chars 570345 :vector 329747 :floats (72 . 111)
> :intervals (348 . 189)
> :strings (21259 . 5705))
>
> After one visit to my INBOX folder (22MB) and quitting:
>
> (:conses (663630 . 605600)
> :syms (32257 . 2608)
> :miscs (15443 . 18022)
> :chars 1639236 :vector 454670 :floats (345 . 261)
> :intervals (503 . 622)
> :strings (99122 . 90256))
>
> After a second visit to the same folder and quitting:
>
> (:conses (1113362 . 334402)
> :syms (32264 . 2807)
> :miscs (15467 . 36265)
> :chars 1833568 :vector 456351 :floats (345 . 328)
> :intervals (604 . 849)
> :strings (138140 . 122806))
Is this with Rmail or with some other mail agent?
With Rmail, I cannot reproduce this with the current trunk. Here are
my results of garbage-collect, the first one is the initial one, the
others are pairs, where the first one is after visiting my 15MB INBOX,
the second one after killing the RMAIL buffer:
((49547 . 8089) (14061 . 0) (21 . 113) 63254 292573 (44 . 78) (322 . 66) (3574 . 2033))
((69953 . 4823) (16430 . 0) (2030 . 3583) 219252 322528 (49 . 73) (373 . 128) (10009 . 4103))
((67776 . 6125) (16430 . 0) (33 . 246) 217261 316518 (49 . 73) (365 . 136) (10006 . 4106))
((70073 . 6199) (16434 . 0) (2032 . 3089) 219400 322528 (49 . 73) (388 . 164) (10016 . 4096))
((67867 . 6905) (16434 . 0) (35 . 340) 217317 316510 (49 . 73) (379 . 137) (10010 . 4102))
((70162 . 6779) (16438 . 0) (2034 . 3007) 219418 322528 (49 . 73) (400 . 167) (10018 . 4094))
((67956 . 7360) (16438 . 0) (37 . 342) 217335 316510 (49 . 73) (391 . 176) (10012 . 4100))
You can see that the counters go up very slowly, much slower than what
you report.
In fact, the initial report in my cases shows counters that are
several times smaller than in your case. Can you explain this
discrepancy?
I see similar numbers in Emacs 23.3, so it's not like the trunk is
very different.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-04 12:19 ` Eli Zaretskii
@ 2011-03-04 12:59 ` Uday S Reddy
0 siblings, 0 replies; 44+ messages in thread
From: Uday S Reddy @ 2011-03-04 12:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Uday S Reddy, emacs-devel
Eli Zaretskii writes:
> Is this with Rmail or with some other mail agent?
Hi Eli, my figures for VM, the mail agent that I maintain. It is much
more of a feature-laden system. So, it probably uses more memory.
But the problem I am after is the one that the memory is leaking, it
is not getting reused.
I don't know yet whether it is a VM problem or an Emacs problem. I am
still trying to understand what is going on.
Any tips would be great!
Cheers,
Uday
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-04 11:39 ` Uday S Reddy
2011-03-04 12:19 ` Eli Zaretskii
@ 2011-03-07 19:19 ` Uday S Reddy
2011-03-07 20:33 ` Andreas Schwab
1 sibling, 1 reply; 44+ messages in thread
From: Uday S Reddy @ 2011-03-07 19:19 UTC (permalink / raw)
To: emacs-devel
On 3/4/2011 11:39 AM, Uday S Reddy wrote:
> After several hours of usage:
>
> (:conses (1558351 . 313757)
> :syms (93011 . 347)
> :miscs (140492 . 28025)
> :chars 9264181 :vector 2283330 :floats (347 . 638)
> :intervals (2771 . 4880)
> :strings (467731 . 34316))
One of the things I have decided to check is what I am doing with
vectors because more than 2M vector slots were being locked up in an
empty Emacs session.
A widespread use of vectors in VM is for obarrays. The code might look
something like this:
(let ((obarray (make-vector 67 0)))
... intern lots of symbols in obarray
(setq buffer-local-var obarray))
I have begun to wonder if obarray gets freed after buffer-local-var
stops pointing to it, say through another setq to buffer-local-var.
Am I supposed to unintern the symbols to free up their memory?
Cheers,
Uday
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: Memory leaks
2011-03-07 19:19 ` Uday S Reddy
@ 2011-03-07 20:33 ` Andreas Schwab
2011-03-07 22:27 ` David Kastrup
2011-03-07 23:01 ` Uday S Reddy
0 siblings, 2 replies; 44+ messages in thread
From: Andreas Schwab @ 2011-03-07 20:33 UTC (permalink / raw)
To: Uday S Reddy; +Cc: emacs-devel
Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> I have begun to wonder if obarray gets freed after buffer-local-var stops
> pointing to it, say through another setq to buffer-local-var.
Obarrays are ordinary vectors, that get garbage collected like any other
object.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-07 20:33 ` Andreas Schwab
@ 2011-03-07 22:27 ` David Kastrup
2011-03-07 22:49 ` David Kastrup
2011-03-09 0:39 ` Richard Stallman
2011-03-07 23:01 ` Uday S Reddy
1 sibling, 2 replies; 44+ messages in thread
From: David Kastrup @ 2011-03-07 22:27 UTC (permalink / raw)
To: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
>
>> I have begun to wonder if obarray gets freed after buffer-local-var stops
>> pointing to it, say through another setq to buffer-local-var.
>
> Obarrays are ordinary vectors, that get garbage collected like any other
> object.
Unfortunately, symbols are daisy-chained from their obarray bucket, so
even unused symbols can't be collected until all their successors in the
hidden hash bucket chain have become unused as well.
--
David Kastrup
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-07 22:27 ` David Kastrup
@ 2011-03-07 22:49 ` David Kastrup
2011-03-09 0:39 ` Richard Stallman
1 sibling, 0 replies; 44+ messages in thread
From: David Kastrup @ 2011-03-07 22:49 UTC (permalink / raw)
To: emacs-devel
David Kastrup <dak@gnu.org> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
>>
>>> I have begun to wonder if obarray gets freed after buffer-local-var stops
>>> pointing to it, say through another setq to buffer-local-var.
>>
>> Obarrays are ordinary vectors, that get garbage collected like any other
>> object.
>
> Unfortunately, symbols are daisy-chained from their obarray bucket, so
> even unused symbols can't be collected until all their successors in
> the hidden hash bucket chain have become unused as well.
Their predecessors I mean.
--
David Kastrup
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-07 22:27 ` David Kastrup
2011-03-07 22:49 ` David Kastrup
@ 2011-03-09 0:39 ` Richard Stallman
1 sibling, 0 replies; 44+ messages in thread
From: Richard Stallman @ 2011-03-09 0:39 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
Unfortunately, symbols are daisy-chained from their obarray bucket, so
even unused symbols can't be collected until all their successors in the
hidden hash bucket chain have become unused as well.
It would not be hard to make GC know how to GC symbols and delete them
from the obarray. This is a traditional Lisp feature that I left out
to make Emacs smaller.
However, it won't do much good unless you create a lot of symbols that
you don't need for long. Is that happening?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-07 20:33 ` Andreas Schwab
2011-03-07 22:27 ` David Kastrup
@ 2011-03-07 23:01 ` Uday S Reddy
2011-03-08 2:35 ` Stefan Monnier
1 sibling, 1 reply; 44+ messages in thread
From: Uday S Reddy @ 2011-03-07 23:01 UTC (permalink / raw)
To: emacs-devel
On 3/7/2011 8:33 PM, Andreas Schwab wrote:
> Uday S Reddy<u.s.reddy@cs.bham.ac.uk> writes:
>
>> I have begun to wonder if obarray gets freed after buffer-local-var stops
>> pointing to it, say through another setq to buffer-local-var.
>
> Obarrays are ordinary vectors, that get garbage collected like any other
> object.
I didn't think the vectors themselves would be in trouble, but rather
what is behind the vectors: the buckets, the symbols and so on. Even
after the vectors are gone, there could be references to the symbols in
other places, could there not? So, it is not entirely clear when all
that memory could be collected?
Cheers,
Uday
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-07 23:01 ` Uday S Reddy
@ 2011-03-08 2:35 ` Stefan Monnier
2011-03-08 8:57 ` Andreas Schwab
0 siblings, 1 reply; 44+ messages in thread
From: Stefan Monnier @ 2011-03-08 2:35 UTC (permalink / raw)
To: Uday S Reddy; +Cc: emacs-devel
>>> I have begun to wonder if obarray gets freed after buffer-local-var stops
>>> pointing to it, say through another setq to buffer-local-var.
>> Obarrays are ordinary vectors, that get garbage collected like any other
>> object.
> I didn't think the vectors themselves would be in trouble, but rather what
> is behind the vectors: the buckets, the symbols and so on. Even after the
> vectors are gone, there could be references to the symbols in other places,
> could there not? So, it is not entirely clear when all that memory could
> be collected?
But then you'd have lots of symbols, not lots of vectors.
Stefan
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: Memory leaks
2011-03-08 2:35 ` Stefan Monnier
@ 2011-03-08 8:57 ` Andreas Schwab
2011-03-09 0:40 ` Richard Stallman
0 siblings, 1 reply; 44+ messages in thread
From: Andreas Schwab @ 2011-03-08 8:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Uday S Reddy, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I have begun to wonder if obarray gets freed after buffer-local-var stops
>>>> pointing to it, say through another setq to buffer-local-var.
>>> Obarrays are ordinary vectors, that get garbage collected like any other
>>> object.
>> I didn't think the vectors themselves would be in trouble, but rather what
>> is behind the vectors: the buckets, the symbols and so on. Even after the
>> vectors are gone, there could be references to the symbols in other places,
>> could there not? So, it is not entirely clear when all that memory could
>> be collected?
>
> But then you'd have lots of symbols, not lots of vectors.
Unless those symbols have lots of vectors as some of their values.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Memory leaks
2011-03-08 8:57 ` Andreas Schwab
@ 2011-03-09 0:40 ` Richard Stallman
2011-03-09 6:07 ` David Kastrup
0 siblings, 1 reply; 44+ messages in thread
From: Richard Stallman @ 2011-03-09 0:40 UTC (permalink / raw)
To: Andreas Schwab; +Cc: u.s.reddy, monnier, emacs-devel
Is it possible to write code to record which vectors were consed by
the operation suspected of having a memory leak? Then a function to
call from GDB to test whether a vector are still alive.
After you find one, you could do a GC with a conditional breakpoint
to stop when that vector is marked. Then you would see exactly
what is keeping it alive. If you do this for each vector that was
consed during the operation in question, you will eventually find
one that was expected to be GC'd, and find the bug.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
^ permalink raw reply [flat|nested] 44+ messages in thread
* Memory leaks
@ 2009-08-05 17:17 Daniel Clemente
2009-08-08 18:57 ` Chong Yidong
0 siblings, 1 reply; 44+ messages in thread
From: Daniel Clemente @ 2009-08-05 17:17 UTC (permalink / raw)
To: emacs-devel
Hi, today my Emacs --daemon from CVS started eating memory and ended up with 1 Gb resident and 2'5 Gb virtual, with only 180 small buffers open.
I wanted to debug who was taking all this memory. Since I don't know how to find out this, I have started to collect more information in EmacsWiki: http://www.emacswiki.org/emacs/EmacsMemoryDebugging
How do you debug memory leaks? Please add tips there so that they are useful to more people.
Thanks
-- Daniel
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2022-03-06 11:15 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-20 7:23 memory leaks Madhu
2019-09-20 8:00 ` Jean-Christophe Helary
2019-09-20 8:11 ` Eli Zaretskii
[not found] ` <mailman.572.1568967069.2190.help-gnu-emacs@gnu.org>
2019-09-20 8:31 ` Madhu
2019-09-20 9:21 ` Eli Zaretskii
[not found] ` <mailman.578.1568971399.2190.help-gnu-emacs@gnu.org>
2020-09-12 13:02 ` Madhu
2020-09-12 13:39 ` Eli Zaretskii
2020-09-12 13:55 ` Michael Heerdegen
2020-09-12 14:09 ` Eli Zaretskii
2020-09-12 19:14 ` Igor Sosa Mayor
2020-09-12 19:26 ` Eli Zaretskii
2020-09-12 19:28 ` Igor Sosa Mayor
2020-09-13 2:30 ` Eli Zaretskii
2020-09-13 3:17 ` Madhu
2020-09-13 14:14 ` Eli Zaretskii
2021-01-21 9:28 ` Madhu
2020-09-13 20:14 ` Stefan Monnier
2020-09-14 10:06 ` Madhu
2020-11-09 17:50 ` Madhu
2022-03-04 11:32 ` Eli Zaretskii
2022-03-06 10:59 ` Madhu
2022-03-06 11:15 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2020-11-10 1:24 Madhu
2020-11-10 15:16 ` Eli Zaretskii
2011-03-03 17:13 Memory leaks Uday S Reddy
2011-03-03 17:55 ` Andreas Schwab
2011-03-03 18:00 ` Uday S Reddy
2011-03-03 23:40 ` Andreas Schwab
2011-03-04 11:39 ` Uday S Reddy
2011-03-04 12:19 ` Eli Zaretskii
2011-03-04 12:59 ` Uday S Reddy
2011-03-07 19:19 ` Uday S Reddy
2011-03-07 20:33 ` Andreas Schwab
2011-03-07 22:27 ` David Kastrup
2011-03-07 22:49 ` David Kastrup
2011-03-09 0:39 ` Richard Stallman
2011-03-07 23:01 ` Uday S Reddy
2011-03-08 2:35 ` Stefan Monnier
2011-03-08 8:57 ` Andreas Schwab
2011-03-09 0:40 ` Richard Stallman
2011-03-09 6:07 ` David Kastrup
2009-08-05 17:17 Daniel Clemente
2009-08-08 18:57 ` Chong Yidong
2009-08-10 8:08 ` Daniel Clemente
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.