* bug#49656: more data on #43389 @ 2021-07-20 7:13 Madhu 2021-07-20 11:43 ` Eli Zaretskii 2021-07-20 11:56 ` bug#49656: more data on #43389 Lars Ingebrigtsen 0 siblings, 2 replies; 10+ messages in thread From: Madhu @ 2021-07-20 7:13 UTC (permalink / raw) To: 49656 [-- Attachment #1: Type: Text/Plain, Size: 809 bytes --] This is the emacs memory bloat issue. I thought I had unarchived the bug earlier but it seems to be closed up again. Should I open a new bug? Its already got a 1000 posts on the bugzilla page Over the past few months, I've experienced the memory problem a few times. I wanted to share the malloc info data I collected on 3 instance and am attaching a tarball with 3 directories named 4 5 6 which include malloc-info, memory-usage, and memory-report data from emacs exhibiting the behaviour - after all buffers are killed and after an M-x gc. Directories 4 and 6 show the common pattern where memory is used unknown to GC. data in directory 5 probably another issue where there are a lot of dead strings. I'd be glad if/when experts can find the time to take a look and see if it offers any further clues. [-- Attachment #2: madhu-emacs-malloc-info-data-20210719.tar.gz --] [-- Type: Application/Octet-Stream, Size: 7042 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-20 7:13 bug#49656: more data on #43389 Madhu @ 2021-07-20 11:43 ` Eli Zaretskii 2021-07-20 16:08 ` Madhu 2021-07-20 11:56 ` bug#49656: more data on #43389 Lars Ingebrigtsen 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-07-20 11:43 UTC (permalink / raw) To: Madhu; +Cc: 49656 > Date: Tue, 20 Jul 2021 12:43:31 +0530 (IST) > From: Madhu <enometh@meer.net> > > This is the emacs memory bloat issue. I thought I had unarchived the > bug earlier but it seems to be closed up again. Should I open a new > bug? Its already got a 1000 posts on the bugzilla page I'm not yet sure this is a bug, FWIW. > Over the past few months, I've experienced the memory problem a few > times. I wanted to share the malloc info data I collected on 3 > instance and am attaching a tarball with 3 directories named 4 5 6 > which include malloc-info, memory-usage, and memory-report data from > emacs exhibiting the behaviour - after all buffers are killed and > after an M-x gc. > > Directories 4 and 6 show the common pattern where memory is used > unknown to GC. data in directory 5 probably another issue where there > are a lot of dead strings. I've looked at the data, thanks. But the most important information is missing from the data you presented. The case where you have 570MB in strings could be interesting, but without knowing what you did in that session, it is impossible to say whether there's an issue there. It could be explained by the live Lisp data you produced in that session. So what we need is the following, for each case separately: . the size of the memory footprint of the Emacs session . how long was the Emacs session running since it started . what were the main activities in that session . do you have some customizations related to GC, and if you do, what are they . what Emacs version is that, and what are its configuration parameters and features compiled into it In general, that old bug is closed, because after making a single change that did cause memory bloat in some usage patterns, we concluded that the rest were user problems caused by messing with GC thresholds. The glibc developers looked at the data we collected and found nothing that could be interpreted as a bug in glibc. TIA ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-20 11:43 ` Eli Zaretskii @ 2021-07-20 16:08 ` Madhu 2021-07-20 17:11 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Madhu @ 2021-07-20 16:08 UTC (permalink / raw) To: eliz; +Cc: 49656 * Eli Zaretskii <eliz@gnu.org> <83o8ax5hxp.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 14:43:46 +0300 >> This is the emacs memory bloat issue. I thought I had unarchived the >> bug earlier but it seems to be closed up again. Should I open a new >> bug? Its already got a 1000 posts on the bugzilla page > I'm not yet sure this is a bug, FWIW. It's been bugging me for a few years now, but I won't mind if you close it. >> Over the past few months, I've experienced the memory problem a few >> times. I wanted to share the malloc info data I collected on 3 >> instance and am attaching a tarball with 3 directories named 4 5 6 >> which include malloc-info, memory-usage, and memory-report data from >> emacs exhibiting the behaviour - after all buffers are killed and >> after an M-x gc. >> Directories 4 and 6 show the common pattern where memory is used >> unknown to GC. data in directory 5 probably another issue where there >> are a lot of dead strings. > I've looked at the data, thanks. But the most important information > is missing from the data you presented. The case where you have 570MB > in strings could be interesting, but without knowing what you did in > that session, it is impossible to say whether there's an issue there. > It could be explained by the live Lisp data you produced in that > session. That 570MB case was the exceptional case - i noticed that only once. In all other cases I hit the memory leak gc thinks it only has 200M while the process has 1.5 to 3.5 GB resident. I don't see how this can be a user error. > So what we need is the following, for each case separately: > . the size of the memory footprint of the Emacs session I have this data for a few runs. The sizes from `ps' correspond exactly to what malloc info shows so i decided to omit it. > . how long was the Emacs session running since it started 2-3 days usually. I always have to kill emacs because I cant suspend the OS to disk because all of it is resident. > . what were the main activities in that session . do you have some > customizations related to GC, and if you do, what are they . what > Emacs version is that, and what are its configuration parameters > and features compiled into it I am not doing anything special with GC. All the recent reports are on Emacs 28, within a month of two of master. The problem is independent of the toolkit, I get it in motif, gtk, and xt. I havent tried a no-x build in 2 years. if you remember I asked on emacs-help once and you informed me of a GC fix and it fixed that problem. > In general, that old bug is closed, because after making a single > change that did cause memory bloat in some usage patterns, we > concluded that the rest were user problems caused by messing with GC > thresholds. The glibc developers looked at the data we collected > and found nothing that could be interpreted as a bug in glibc. But doesn't the malloc info allocation and the gc reports indicate a clear discrepancy? Does it not indicate a leak which the GC is not aware of? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-20 16:08 ` Madhu @ 2021-07-20 17:11 ` Eli Zaretskii 2021-07-21 1:46 ` Madhu 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-07-20 17:11 UTC (permalink / raw) To: Madhu; +Cc: 49656 > Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) > Cc: 49656@debbugs.gnu.org > From: Madhu <enometh@meer.net> > > In all other cases I hit the memory leak gc thinks it only has 200M > while the process has 1.5 to 3.5 GB resident. > > I don't see how this can be a user error. It could be if, for example, you are using packages or your own code which plays with GC thresholds. E.g., I'm told that lsp-mode does that; are you per chance using it? > > So what we need is the following, for each case separately: > > . the size of the memory footprint of the Emacs session > > I have this data for a few runs. The sizes from `ps' correspond > exactly to what malloc info shows so i decided to omit it. Ah, but gleaning this from the malloc info takes some time, so telling the number explicitly will help making the report more easily understandable. > > . how long was the Emacs session running since it started > > 2-3 days usually. I always have to kill emacs because I cant suspend > the OS to disk because all of it is resident. How much memory and swap do you have there? Can you enlarge the total VM size (by enlarging swap) so that you could run Emacs longer when it gets to such large sizes? Btw, 1.5GB is not too large for several days worth of work. > > . what were the main activities in that session . do you have some > > customizations related to GC, and if you do, what are they . what > > Emacs version is that, and what are its configuration parameters > > and features compiled into it > > I am not doing anything special with GC. Are you sure no package you use does something like that? What were the values of GC thresholds when the memory was large? Was the value of gcs-done increasing with time, or did it stay put (which would be an evidence that Emacs doesn't run GC at all)? If GC was running, how frequently did it run? (You could answer the last question either by looking at the rate of growth in gcs-done, or by setting garbage-collection-messages non-nil, which will cause Emacs announce ever GC in the echo area.) > if you remember I asked on emacs-help once and you informed me of a GC > fix and it fixed that problem. But that problem was fixed, so it cannot possibly affect you now. And we found that problem because the user reported lack of GC cycles after some point. > But doesn't the malloc info allocation and the gc reports indicate a > clear discrepancy? Not to me, it doesn't. It means the malloc arena holds to a lot of memory that it cannot release to the OS, but it is known that this can happen for certain patterns of memory allocation and deallocation. You can find explanations of why this happens on the net. > Does it not indicate a leak which the GC is not aware of? No. Emacs allocates a lot of memory for purposes other than Lisp objects, and that memory is not visible to GC nor to memory-report. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-20 17:11 ` Eli Zaretskii @ 2021-07-21 1:46 ` Madhu 2021-07-21 12:21 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Madhu @ 2021-07-21 1:46 UTC (permalink / raw) To: eliz; +Cc: 49656 * Eli Zaretskii <eliz@gnu.org> <837dhk6hby.fsf@gnu.org> Wrote on Tue, 20 Jul 2021 20:11:29 +0300 >> Date: Tue, 20 Jul 2021 21:38:37 +0530 (IST) >> From: Madhu <enometh@meer.net> >> >> In all other cases I hit the memory leak gc thinks it only has 200M >> while the process has 1.5 to 3.5 GB resident. >> >> I don't see how this can be a user error. > > It could be if, for example, you are using packages or your own code > which plays with GC thresholds. E.g., I'm told that lsp-mode does > that; are you per chance using it? No I haven't gotten around to trying that i'm sure none of my packages mess with gc-threshold. I will double check that. > How much memory and swap do you have there? Can you enlarge the total > VM size (by enlarging swap) so that you could run Emacs longer when it > gets to such large sizes? The problem is not that emacs won't run. I am unable to use the memory in the machine for other purposes and am obliged to kill emacs. > Btw, 1.5GB is not too large for several days worth of work. I also have emacs running for several weeks when the problem doesn't happen with RES never above say 500M for the same workloads and usage patterns. > Are you sure no package you use does something like that? What were > the values of GC thresholds when the memory was large? Yes I do not run a lot of packages and certainly nothing that I don't audit first - I am aware of all the packages that are loaded at least in the exceptional cases. There is no reason for me to suspect those packages because I use them all the time in emacs sessions where the problem does not manifest. > Was the value of gcs-done increasing with time, or did it stay put > (which would be an evidence that Emacs doesn't run GC at all)? If > GC was running, how frequently did it run? (You could answer the > last question either by looking at the rate of growth in gcs-done, > or by setting garbage-collection-messages non-nil, which will cause > Emacs announce ever GC in the echo area.) There is nothing exceptional with GC. GC usually completes quickly because it doesnt access much memory. >> But doesn't the malloc info allocation and the gc reports indicate a >> clear discrepancy? > > Not to me, it doesn't. It means the malloc arena holds to a lot of > memory that it cannot release to the OS, but it is known that this can > happen for certain patterns of memory allocation and deallocation. > You can find explanations of why this happens on the net. But that is the point - I've been asking from the first time I posted on this - WHAT is emacs allocating in these exceptional cases. I understand my usage patterns over the years of constant emacs use and the "random" memory bloat in some sessions makes no sense and it only suggests a memory leak in emacs code. >> Does it not indicate a leak which the GC is not aware of? > > No. Emacs allocates a lot of memory for purposes other than Lisp > objects, and that memory is not visible to GC nor to memory-report. This is too vague. This 2GB active memory is not legitimate and the point is to figure out where and why emacs is holding on to this memory. This is where I need assistance. my usage patterns are pretty deterministic The memory usage of the qlisp packages I use would show up in GC. SO what could that be, which it is NOT allocating under identical usage patterns? It isn't fonts or external images or anything else I can see. I'm sure others should be hitting the problem too ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-21 1:46 ` Madhu @ 2021-07-21 12:21 ` Eli Zaretskii 2022-08-21 18:06 ` bug#49656: Abnormal Emacs memory usage (bug#43389) Lars Ingebrigtsen 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2021-07-21 12:21 UTC (permalink / raw) To: Madhu; +Cc: 49656 > Date: Wed, 21 Jul 2021 07:16:23 +0530 (IST) > Cc: 49656@debbugs.gnu.org > From: Madhu <enometh@meer.net> > > > It could be if, for example, you are using packages or your own code > > which plays with GC thresholds. E.g., I'm told that lsp-mode does > > that; are you per chance using it? > > No I haven't gotten around to trying that i'm sure none of my packages > mess with gc-threshold. I will double check that. Thanks, please do. It's important to know that. > > How much memory and swap do you have there? Can you enlarge the total > > VM size (by enlarging swap) so that you could run Emacs longer when it > > gets to such large sizes? > > The problem is not that emacs won't run. I am unable to use the > memory in the machine for other purposes and am obliged to kill emacs. If you enlarge the swap space, your system will still be workable even when Emacs has such a large footprint. That's the purpose of my suggestion. It is important to have a usable system when these situations happen because if we come up with some experiments to conduct in such cases, you need a usable system to be able to do that. > > Btw, 1.5GB is not too large for several days worth of work. > > I also have emacs running for several weeks when the problem doesn't > happen with RES never above say 500M for the same workloads and usage > patterns. Then one thing to try to figure out is what was the difference between these two classes of sessions -- what and how did you do differently in one that you didn't in the other? That could point us in the right direction. > > Was the value of gcs-done increasing with time, or did it stay put > > (which would be an evidence that Emacs doesn't run GC at all)? If > > GC was running, how frequently did it run? (You could answer the > > last question either by looking at the rate of growth in gcs-done, > > or by setting garbage-collection-messages non-nil, which will cause > > Emacs announce ever GC in the echo area.) > > There is nothing exceptional with GC. GC usually completes quickly > because it doesnt access much memory. I'd like quantitative measures, please: what is the rate of GC cycles when the memory footprint is measurd in GBs, and how much time does each GC cycle take? Also, does the memory footprint becomes smaller after a GC cycle, and by how much? > >> But doesn't the malloc info allocation and the gc reports indicate a > >> clear discrepancy? > > > > Not to me, it doesn't. It means the malloc arena holds to a lot of > > memory that it cannot release to the OS, but it is known that this can > > happen for certain patterns of memory allocation and deallocation. > > You can find explanations of why this happens on the net. > > But that is the point - I've been asking from the first time I posted > on this - WHAT is emacs allocating in these exceptional cases. It's impractical to try to answer these questions. If you put a breakpoint on 'malloc' and 'free' and then run Emacs, you will see that it calls these functions extremely frequently, with widely different block sizes. We don't have infrastructure that would record each allocation and deallocation with enough info to be able to analyze that, and even if we did, finding the callers which are responsible for the memory that's not returned to the OS is a very large and hard job. We tried that previously, with the help of the glibc developers using their debugging features -- it didn't really help us with the diagnostics. > I understand my usage patterns over the years of constant emacs use > and the "random" memory bloat in some sessions makes no sense and it > only suggests a memory leak in emacs code. It is impossible to look for memory leaks in Emacs without some clues about where those leaks could be. If you can provide the information I asked above, we might be able to come up with such clues. Alternatively, you could try running Emacs under Valgrind (see instructions in etc/DEBUG), although this will probably catch memory leaks only on the C level, not on the Lisp level. > >> Does it not indicate a leak which the GC is not aware of? > > > > No. Emacs allocates a lot of memory for purposes other than Lisp > > objects, and that memory is not visible to GC nor to memory-report. > > This is too vague. But that's all I can say, given the information you provided till now. > This 2GB active memory is not legitimate and the point is to figure > out where and why emacs is holding on to this memory. > > This is where I need assistance. This is me assisting you. I'm asking you to help us analyze this problem by providing more information. I don't think we will be able to make progress here without that additional info. > SO what could that be, which it is NOT allocating under identical > usage patterns? I don't know, sorry. > I'm sure others should be hitting the problem too We could, of course, wait for others to report similar problems, and then hope the information they provide would point us to the right direction. IME, though, this is not a very efficient method, because in many cases the reasons for the memory growth are not the same. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: Abnormal Emacs memory usage (bug#43389) 2021-07-21 12:21 ` Eli Zaretskii @ 2022-08-21 18:06 ` Lars Ingebrigtsen 2022-08-22 2:07 ` Madhu 0 siblings, 1 reply; 10+ messages in thread From: Lars Ingebrigtsen @ 2022-08-21 18:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Madhu, 49656 Eli Zaretskii <eliz@gnu.org> writes: >> No I haven't gotten around to trying that i'm sure none of my packages >> mess with gc-threshold. I will double check that. > > Thanks, please do. It's important to know that. (I'm going through old bug reports that unfortunately weren't resolved at the time.) This was a year ago -- Madhu, did you make any progress in identifying the problem (if you're still seeing it)? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: Abnormal Emacs memory usage (bug#43389) 2022-08-21 18:06 ` bug#49656: Abnormal Emacs memory usage (bug#43389) Lars Ingebrigtsen @ 2022-08-22 2:07 ` Madhu 2022-08-22 10:06 ` Lars Ingebrigtsen 0 siblings, 1 reply; 10+ messages in thread From: Madhu @ 2022-08-22 2:07 UTC (permalink / raw) To: larsi; +Cc: eliz, 49656 * Lars Ingebrigtsen <larsi@gnus.org> <871qt9bhe1.fsf_-_@gnus.org> Wrote on Sun, 21 Aug 2022 20:06:46 +0200 > Eli Zaretskii <eliz@gnu.org> writes: >>> No I haven't gotten around to trying that i'm sure none of my packages >>> mess with gc-threshold. I will double check that. >> >> Thanks, please do. It's important to know that. > > (I'm going through old bug reports that unfortunately weren't resolved > at the time.) > > This was a year ago -- Madhu, did you make any progress in identifying > the problem (if you're still seeing it)? No, I haven't triggered this problem recently with emacs-29. Maybe I've stopped using the packages that triggered it. The bug should be probably closed, Thanks ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: Abnormal Emacs memory usage (bug#43389) 2022-08-22 2:07 ` Madhu @ 2022-08-22 10:06 ` Lars Ingebrigtsen 0 siblings, 0 replies; 10+ messages in thread From: Lars Ingebrigtsen @ 2022-08-22 10:06 UTC (permalink / raw) To: Madhu; +Cc: eliz, 49656 Madhu <enometh@meer.net> writes: > No, I haven't triggered this problem recently with emacs-29. Maybe > I've stopped using the packages that triggered it. The bug should be > probably closed, Thanks OK; done. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49656: more data on #43389 2021-07-20 7:13 bug#49656: more data on #43389 Madhu 2021-07-20 11:43 ` Eli Zaretskii @ 2021-07-20 11:56 ` Lars Ingebrigtsen 1 sibling, 0 replies; 10+ messages in thread From: Lars Ingebrigtsen @ 2021-07-20 11:56 UTC (permalink / raw) To: Madhu; +Cc: 49656 Madhu <enometh@meer.net> writes: > This is the emacs memory bloat issue. I thought I had unarchived the > bug earlier but it seems to be closed up again. Unarchiving a bug doesn't reopen it -- you have to do both. > Should I open a new bug? Its already got a 1000 posts on the bugzilla > page You did open a new bug report. :-) bug#49656. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-22 10:06 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-07-20 7:13 bug#49656: more data on #43389 Madhu 2021-07-20 11:43 ` Eli Zaretskii 2021-07-20 16:08 ` Madhu 2021-07-20 17:11 ` Eli Zaretskii 2021-07-21 1:46 ` Madhu 2021-07-21 12:21 ` Eli Zaretskii 2022-08-21 18:06 ` bug#49656: Abnormal Emacs memory usage (bug#43389) Lars Ingebrigtsen 2022-08-22 2:07 ` Madhu 2022-08-22 10:06 ` Lars Ingebrigtsen 2021-07-20 11:56 ` bug#49656: more data on #43389 Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).