GNU bug report logs - #38345
27.0.50; Permanent increase in memory consumption after opening images (or pdfs)

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> gmail.com>

Date: Sat, 23 Nov 2019 14:40:03 UTC

Severity: normal

Tags: fixed

Found in version 27.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38345 in the body.
You can then email your comments to 38345 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 14:40:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ihor Radchenko <yantar92 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 23 Nov 2019 14:40:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Permanent increase in memory consumption after opening
 images (or pdfs)
Date: Sat, 23 Nov 2019 22:37:44 +0800
Recently, I have noticed that my emacs tends to increase its memory
usage up to over 1.5Gb after I open a large number of pdf documents. It
is understandable since some of the pdfs can be quite large. However,
the problem is that the memory does not seem to be released even after I
close all the pdf buffers.

First, I though that the issue is with pdf-tools and reported my problem
there (https://github.com/politza/pdf-tools/issues/177). However, the
memory consumption problem appears to happen even if I just open images.

I monitored emacs (emacs -Q) memory usage with 
https://github.com/dkogan/memory_leak_instrumentation

If I open a large (>250) photos using the code below, the memory usage
increases permanently even after I close all the image buffers and wait
for some time. 

#+begin_src emacs-lisp
(setq large-file-warning-threshold nil)
(setq image-cache-eviction-delay 5)
(find-file "~/Tosort/pictures&photos/*.jpg" 'wild)
(mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
(clear-image-cache t)
(garbage-collect)
#+end_src

The attached is memory consumption plot I got after running M-x
eval-buffer on the code above several times (each run correspond to the
memory consumption peak on the plot).

Regards,
Ihor

in GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2019-11-21 built on yantar92-laptop
Repository revision: 1805b4cc08c8f9668f0f43f5b157d91b9c757e88
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Gentoo/Linux





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 14:48:14 GMT) Full text and rfc822 format available.

Message #8 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: Acknowledgement (27.0.50; Permanent increase in
 memory consumption after opening images (or pdfs))
Date: Sat, 23 Nov 2019 22:44:21 +0800
[Message part 1 (text/plain, inline)]
Forgot to attach the memory consumption plot.
Here is goes.

[images2.png (image/png, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 14:50:03 GMT) Full text and rfc822 format available.

Message #11 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 15:48:30 +0100
Ihor Radchenko <yantar92 <at> gmail.com> writes:

> Recently, I have noticed that my emacs tends to increase its memory
> usage up to over 1.5Gb after I open a large number of pdf documents. It
> is understandable since some of the pdfs can be quite large. However,
> the problem is that the memory does not seem to be released even after I
> close all the pdf buffers.

If you say

  M-: (clear-image-cache)

is the memory released?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 14:51:01 GMT) Full text and rfc822 format available.

Message #14 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Sat, 23 Nov 2019 16:50:28 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Sat, 23 Nov 2019 22:37:44 +0800
> 
> Recently, I have noticed that my emacs tends to increase its memory
> usage up to over 1.5Gb after I open a large number of pdf documents. It
> is understandable since some of the pdfs can be quite large. However,
> the problem is that the memory does not seem to be released even after I
> close all the pdf buffers.
> 
> First, I though that the issue is with pdf-tools and reported my problem
> there (https://github.com/politza/pdf-tools/issues/177). However, the
> memory consumption problem appears to happen even if I just open images.
> 
> I monitored emacs (emacs -Q) memory usage with 
> https://github.com/dkogan/memory_leak_instrumentation
> 
> If I open a large (>250) photos using the code below, the memory usage
> increases permanently even after I close all the image buffers and wait
> for some time. 
> 
> #+begin_src emacs-lisp
> (setq large-file-warning-threshold nil)
> (setq image-cache-eviction-delay 5)
> (find-file "~/Tosort/pictures&photos/*.jpg" 'wild)
> (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
> (clear-image-cache t)
> (garbage-collect)
> #+end_src
> 
> The attached is memory consumption plot I got after running M-x
> eval-buffer on the code above several times (each run correspond to the
> memory consumption peak on the plot).

I see no attachment here, but isn't this because Emacs never returns
memory to the system when it frees it?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 15:16:03 GMT) Full text and rfc822 format available.

Message #17 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 23:12:47 +0800
> If you say
>
>   M-: (clear-image-cache)
>
> is the memory released?

The command is called in the code I provided.
When I call it manually, I can see that some part of memory is being
released. However, it is just a small fraction.

Best,
Ihor

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Ihor Radchenko <yantar92 <at> gmail.com> writes:
>
>> Recently, I have noticed that my emacs tends to increase its memory
>> usage up to over 1.5Gb after I open a large number of pdf documents. It
>> is understandable since some of the pdfs can be quite large. However,
>> the problem is that the memory does not seem to be released even after I
>> close all the pdf buffers.
>
> If you say
>
>   M-: (clear-image-cache)
>
> is the memory released?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 15:21:02 GMT) Full text and rfc822 format available.

Message #20 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 23:18:21 +0800
[Message part 1 (text/plain, inline)]
> I see no attachment here, but isn't this because Emacs never returns
> memory to the system when it frees it?

Sorry, I forgot to send the attachment in the first message. I have sent
a followup, but also attaching here just in case.

What you say about Emacs not returning memory sounds like very very
strange behaviour unless I misunderstand something. Does it mean that if
I have emacs running as daemon and open a few hundreds of heavy pdfs
during, say, a week, it will keep all the memory allocated for those pdfs
(which is several Gb, at least)? If so, I don't think that Emacs should
do it.

Regards,
Ihor

[images2.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Date: Sat, 23 Nov 2019 22:37:44 +0800
>> 
>> Recently, I have noticed that my emacs tends to increase its memory
>> usage up to over 1.5Gb after I open a large number of pdf documents. It
>> is understandable since some of the pdfs can be quite large. However,
>> the problem is that the memory does not seem to be released even after I
>> close all the pdf buffers.
>> 
>> First, I though that the issue is with pdf-tools and reported my problem
>> there (https://github.com/politza/pdf-tools/issues/177). However, the
>> memory consumption problem appears to happen even if I just open images.
>> 
>> I monitored emacs (emacs -Q) memory usage with 
>> https://github.com/dkogan/memory_leak_instrumentation
>> 
>> If I open a large (>250) photos using the code below, the memory usage
>> increases permanently even after I close all the image buffers and wait
>> for some time. 
>> 
>> #+begin_src emacs-lisp
>> (setq large-file-warning-threshold nil)
>> (setq image-cache-eviction-delay 5)
>> (find-file "~/Tosort/pictures&photos/*.jpg" 'wild)
>> (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
>> (clear-image-cache t)
>> (garbage-collect)
>> #+end_src
>> 
>> The attached is memory consumption plot I got after running M-x
>> eval-buffer on the code above several times (each run correspond to the
>> memory consumption peak on the plot).
>
> I see no attachment here, but isn't this because Emacs never returns
> memory to the system when it frees it?

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92 <at> gmail.com, ihor_radchenko <at> alumni.sutd.edu.sg

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 15:46:02 GMT) Full text and rfc822 format available.

Message #23 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 17:45:09 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: 38345 <at> debbugs.gnu.org
> Date: Sat, 23 Nov 2019 23:18:21 +0800
> 
> What you say about Emacs not returning memory sounds like very very
> strange behaviour unless I misunderstand something. Does it mean that if
> I have emacs running as daemon and open a few hundreds of heavy pdfs
> during, say, a week, it will keep all the memory allocated for those pdfs
> (which is several Gb, at least)? If so, I don't think that Emacs should
> do it.

It depends on how the memory is allocated.  Memory allocated for
buffers gets returned to the OS when those buffers are killed.  But
memory allocated via malloc AFAIK gets grafted into the program's
address space, and when it is freed, it is left in the program's
address space, free to be used by that program for any further
allocation -- but is not returned to the system.  So if you look at
the program's address space, you will think it only ever grows,
especially if you allocate a lot of memory before releasing the first
allocation.

At least that's what I think happens on modern platforms.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 16:07:02 GMT) Full text and rfc822 format available.

Message #26 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sun, 24 Nov 2019 00:04:17 +0800
> memory allocated via malloc AFAIK gets grafted into the program's
> address space, and when it is freed, it is left in the program's
> address space, free to be used by that program for any further
> allocation -- but is not returned to the system.  So if you look at
> the program's address space, you will think it only ever grows,
> especially if you allocate a lot of memory before releasing the first
> allocation.

Hmm. Following an article by Dima Kogan [1], it appears to me that free()
should de-allocate memory in the program's address space (or at least
memory drop should be visible in the plot I got, since I used the same
memory debugging tools)

Best,
Ihor

[1] http://notes.secretsauce.net/notes/2015/10/05_memory-leak-debugging-tools.html


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: 38345 <at> debbugs.gnu.org
>> Date: Sat, 23 Nov 2019 23:18:21 +0800
>> 
>> What you say about Emacs not returning memory sounds like very very
>> strange behaviour unless I misunderstand something. Does it mean that if
>> I have emacs running as daemon and open a few hundreds of heavy pdfs
>> during, say, a week, it will keep all the memory allocated for those pdfs
>> (which is several Gb, at least)? If so, I don't think that Emacs should
>> do it.
>
> It depends on how the memory is allocated.  Memory allocated for
> buffers gets returned to the OS when those buffers are killed.  But
> memory allocated via malloc AFAIK gets grafted into the program's
> address space, and when it is freed, it is left in the program's
> address space, free to be used by that program for any further
> allocation -- but is not returned to the system.  So if you look at
> the program's address space, you will think it only ever grows,
> especially if you allocate a lot of memory before releasing the first
> allocation.
>
> At least that's what I think happens on modern platforms.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 16:35:18 GMT) Full text and rfc822 format available.

Message #29 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 18:34:22 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: 38345 <at> debbugs.gnu.org
> Date: Sun, 24 Nov 2019 00:04:17 +0800
> 
> Hmm. Following an article by Dima Kogan [1], it appears to me that free()
> should de-allocate memory in the program's address space (or at least
> memory drop should be visible in the plot I got, since I used the same
> memory debugging tools)

It may be useful to try memory mapping tools that show which part(s)
of a program "own" specific regions of memory.  It could be that the
memory growth is due to some library Emacs uses to show images, for
example.  Those tools usually also show the memory in the free pool of
the program's address space, so you should be able to see what's going
on when you call clear-image-cache.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 17:53:03 GMT) Full text and rfc822 format available.

Message #32 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sat, 23 Nov 2019 19:51:30 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: 38345 <at> debbugs.gnu.org
> Date: Sun, 24 Nov 2019 01:33:29 +0800
> 
> The full info from smaps and output from pmap are attached:
> *0.txt ::  Before opening images
> *open.txt :: With all the image buffers
> *kill.txt :: After killing all the image buffers
> *clear.txt :: After clearing cache and garbage collecting

I'm not an expert, but AFAIK "anon" means buffer memory.

I hope someone more knowledgeable will chime in, though.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sat, 23 Nov 2019 17:53:03 GMT) Full text and rfc822 format available.

Message #35 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sun, 24 Nov 2019 01:33:29 +0800
[Message part 1 (text/plain, inline)]
> It may be useful to try memory mapping tools that show which part(s)
> of a program "own" specific regions of memory.  It could be that the
> memory growth is due to some library Emacs uses to show images, for
> example.  Those tools usually also show the memory in the free pool of
> the program's address space, so you should be able to see what's going
> on when you call clear-image-cache.

I tried to follow EmacsWiki
(https://www.emacswiki.org/emacs/EmacsMemoryDebugging).

The largest entry in smaps:

1. Before opening images

562e4cf38000-562e4d395000 rw-p 00000000 00:00 0                          [heap]
Size:               4468 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                4148 kB
Pss:                4148 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:      4148 kB
Referenced:         4148 kB
Anonymous:          4148 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
THPeligible:		0
VmFlags: rd wr mr mw me ac

2. After opening images with all the buffers open

562e4cf38000-562e945a5000 rw-p 00000000 00:00 0                          [heap]
Size:            1169844 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:             1169500 kB
Pss:             1169500 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1169500 kB
Referenced:      1169500 kB
Anonymous:       1169500 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
THPeligible:		0
VmFlags: rd wr mr mw me ac

3. After killing all the image buffers

562e4cf38000-562e945a5000 rw-p 00000000 00:00 0                          [heap]
Size:            1169844 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:             1169692 kB
Pss:             1169692 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1169692 kB
Referenced:      1169692 kB
Anonymous:       1169692 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
THPeligible:		0
VmFlags: rd wr mr mw me ac

4. After calling (clear-image-cache t) and (garbage-collect)

562e4cf38000-562e945a5000 rw-p 00000000 00:00 0                          [heap]
Size:            1169844 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:             1169692 kB
Pss:             1169692 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1169692 kB
Referenced:      1169692 kB
Anonymous:       1169692 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
THPeligible:		0
VmFlags: rd wr mr mw me ac 

The full info from smaps and output from pmap are attached:
*0.txt ::  Before opening images
*open.txt :: With all the image buffers
*kill.txt :: After killing all the image buffers
*clear.txt :: After clearing cache and garbage collecting

I also attempted to use perf, but I cannot understand much of
information from there and I was not able to make the scripts I use work
with the output. If you need, I can also generate perf output (may take
some time).

Regards,
Ihor

[pmap0.txt (text/plain, attachment)]
[pmap-open.txt (text/plain, attachment)]
[pmap-kill.txt (text/plain, attachment)]
[pmap-clear.txt (text/plain, attachment)]
[smaps0.txt (text/plain, attachment)]
[smaps-open.txt (text/plain, attachment)]
[smaps-kill.txt (text/plain, attachment)]
[smaps-clear.txt (text/plain, attachment)]
[Message part 10 (text/plain, inline)]





Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: 38345 <at> debbugs.gnu.org
>> Date: Sun, 24 Nov 2019 00:04:17 +0800
>> 
>> Hmm. Following an article by Dima Kogan [1], it appears to me that free()
>> should de-allocate memory in the program's address space (or at least
>> memory drop should be visible in the plot I got, since I used the same
>> memory debugging tools)
>
> It may be useful to try memory mapping tools that show which part(s)
> of a program "own" specific regions of memory.  It could be that the
> memory growth is due to some library Emacs uses to show images, for
> example.  Those tools usually also show the memory in the free pool of
> the program's address space, so you should be able to see what's going
> on when you call clear-image-cache.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 25 Nov 2019 16:11:01 GMT) Full text and rfc822 format available.

Message #38 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Mon, 25 Nov 2019 18:10:50 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Sat, 23 Nov 2019 22:37:44 +0800
> 
> If I open a large (>250) photos using the code below, the memory usage
> increases permanently even after I close all the image buffers and wait
> for some time. 

For some background on this, see

  https://unix.stackexchange.com/questions/53447/does-free-unmap-the-memory-of-a-process
  https://stackoverflow.com/questions/1421491/does-calling-free-or-delete-ever-release-memory-back-to-the-system

I think what you see is just normal behavior of memory allocation in
glibc.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Tue, 26 Nov 2019 15:24:01 GMT) Full text and rfc822 format available.

Message #41 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Tue, 26 Nov 2019 23:21:11 +0800
[Message part 1 (text/plain, inline)]
Thanks for the links. I got to know more about memory management now.
Now, it is clear why the memory is consumption is so high when I open a
bunch of images at the same time. However, it still does not explain my
observations during usual workflow.

For my real usage, I open pdfs (or images) one by one most of the time
and kill the buffers periodically.
Then, if the memory is freed upon closing a pdf buffer, I expect it to
be reused for opening a new buffer. Even though memory consumption is
expected to grow in this case, it should be in order of the largest
image I open (times maximum number of image buffers open at the same
time). But it is not what I see.

I did a small test by modifying my earlier lisp code to open and close
the same image list sequentially:

#+begin_src emacs-lisp
(dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
  (find-file file)
  (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list)))))
#+end_src

The resulting memory usage graph is attached.

What we can see is that the memory is indeed growing (as expected).
Moreover, the memory consumption does not increase as much as if we open
all the images together. However, the final heap size appears to be over
400Mb (from smaps), which is almost half of what was observed with all
the images open at the same time. Since the largest .jpg file I have in
the folder is just around 5.5Mb, 400Mb sounds strange for me. Googling
on memory consumption issues, I found that there might be some memory
fragmentation problem happening [1].

P.S. Were there any attempts to implement garbage collection for emacs
in C code? I found an article [2] showing that using an actual GC may speed
up an application in comparison with malloc/free approach. 


[1] https://stackoverflow.com/a/9069474/9196985
[2] https://www.linuxjournal.com/article/6679

Regards,
Ihor

[images-seq.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Date: Sat, 23 Nov 2019 22:37:44 +0800
>> 
>> If I open a large (>250) photos using the code below, the memory usage
>> increases permanently even after I close all the image buffers and wait
>> for some time. 
>
> For some background on this, see
>
>   https://unix.stackexchange.com/questions/53447/does-free-unmap-the-memory-of-a-process
>   https://stackoverflow.com/questions/1421491/does-calling-free-or-delete-ever-release-memory-back-to-the-system
>
> I think what you see is just normal behavior of memory allocation in
> glibc.


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Tue, 26 Nov 2019 15:56:02 GMT) Full text and rfc822 format available.

Message #44 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Tue, 26 Nov 2019 17:55:47 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: 38345 <at> debbugs.gnu.org
> Date: Tue, 26 Nov 2019 23:21:11 +0800
> 
> I did a small test by modifying my earlier lisp code to open and close
> the same image list sequentially:
> 
> #+begin_src emacs-lisp
> (dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
>   (find-file file)
>   (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list)))))
> #+end_src
> 
> The resulting memory usage graph is attached.
> 
> What we can see is that the memory is indeed growing (as expected).
> Moreover, the memory consumption does not increase as much as if we open
> all the images together. However, the final heap size appears to be over
> 400Mb (from smaps), which is almost half of what was observed with all
> the images open at the same time.

Does it help to call garbage-collect after killing each buffer and
before visiting the next image file?

> P.S. Were there any attempts to implement garbage collection for emacs
> in C code?

I don't understand the question, sorry.  GC in Emacs is implemented in
C, not in Lisp.  If you mean to use a garbage-collecting memory
allocator, then we once had that only for buffer text, but nowadays
system malloc is good enough for that, so we no longer use it.  Doing
that for "normal" C code is not easy because it generally requires
double indirection for accessing data through pointers.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Tue, 26 Nov 2019 16:27:02 GMT) Full text and rfc822 format available.

Message #47 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Wed, 27 Nov 2019 00:24:40 +0800
> Does it help to call garbage-collect after killing each buffer and
> before visiting the next image file?

No. It makes no difference.

> I don't understand the question, sorry.  GC in Emacs is implemented in
> C, not in Lisp.  If you mean to use a garbage-collecting memory
> allocator, then we once had that only for buffer text, but nowadays
> system malloc is good enough for that, so we no longer use it.  Doing
> that for "normal" C code is not easy because it generally requires
> double indirection for accessing data through pointers.

Yes, I meant garbage collecting malloc. I don't know much about this
topic. Just stumbled on an article saying that it can speed up
performance.

Regards,
Ihor


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: 38345 <at> debbugs.gnu.org
>> Date: Tue, 26 Nov 2019 23:21:11 +0800
>> 
>> I did a small test by modifying my earlier lisp code to open and close
>> the same image list sequentially:
>> 
>> #+begin_src emacs-lisp
>> (dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
>>   (find-file file)
>>   (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list)))))
>> #+end_src
>> 
>> The resulting memory usage graph is attached.
>> 
>> What we can see is that the memory is indeed growing (as expected).
>> Moreover, the memory consumption does not increase as much as if we open
>> all the images together. However, the final heap size appears to be over
>> 400Mb (from smaps), which is almost half of what was observed with all
>> the images open at the same time.
>
> Does it help to call garbage-collect after killing each buffer and
> before visiting the next image file?
>
>> P.S. Were there any attempts to implement garbage collection for emacs
>> in C code?
>
> I don't understand the question, sorry.  GC in Emacs is implemented in
> C, not in Lisp.  If you mean to use a garbage-collecting memory
> allocator, then we once had that only for buffer text, but nowadays
> system malloc is good enough for that, so we no longer use it.  Doing
> that for "normal" C code is not easy because it generally requires
> double indirection for accessing data through pointers.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Wed, 27 Nov 2019 21:56:02 GMT) Full text and rfc822 format available.

Message #50 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Wed, 27 Nov 2019 23:17:12 +0200
> Thanks for the links. I got to know more about memory management now.
> Now, it is clear why the memory is consumption is so high when I open a
> bunch of images at the same time. However, it still does not explain my
> observations during usual workflow.

Please see also the recent discussion in
https://debbugs.gnu.org/38187#95




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 01:41:02 GMT) Full text and rfc822 format available.

Message #53 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38345 <at> debbugs.gnu.org
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 28 Nov 2019 09:38:34 +0800
[Message part 1 (text/plain, inline)]
> Please see also the recent discussion in
> https://debbugs.gnu.org/38187#95

Thanks.

Similar to that discussion, I tried to force clearing the image cache
after killing each image buffer.

#+begin_sec emacs-lisp
(dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
  (find-file file)
  (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
  (garbage-collect)
  (clear-image-cache t))
#+end_src

The resulting memory consumption graph is attached.
The memory increase almost disappeared (remaining heap size becomes
~40Mb in comparison ~400Mb in the version with just garbage collect).

Just calling (clear-image-cache) after cycling over opening/killing
the image buffers still results in ~400Mb (it has no effect, basically).

The above result is confusing since the all the code I tried to run so
far had (setq image-cache-eviction-delay 5). Since, cycling over all the
images usually took >1min, cache clearing supposed to happen at least
several times during opening/killing the image buffers.

To understand further, I tried to disable automatic cache clearing
completely (setq image-cache-eviction-delay 5000). The resulting memory
consumption is ~400Mb, but a few tens of Mb higher in comparison with
(setq image-cache-eviction-delay 5).

It appears to me that clearing image cache has some problem when there
is a relatively large number of images in the cache already.


Regards,
Ihor

[images-seq-flush.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> writes:

>> Thanks for the links. I got to know more about memory management now.
>> Now, it is clear why the memory is consumption is so high when I open a
>> bunch of images at the same time. However, it still does not explain my
>> observations during usual workflow.
>
> Please see also the recent discussion in
> https://debbugs.gnu.org/38187#95


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 12:36:01 GMT) Full text and rfc822 format available.

Message #56 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 28 Nov 2019 13:35:30 +0100
Ihor Radchenko <yantar92 <at> gmail.com> writes:

> It appears to me that clearing image cache has some problem when there
> is a relatively large number of images in the cache already.

When Emacs frees memory, it's not normally returned to the OS.  Is that
what you're seeing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 13:14:01 GMT) Full text and rfc822 format available.

Message #59 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38345 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 28 Nov 2019 21:11:25 +0800
> When Emacs frees memory, it's not normally returned to the OS.  Is that
> what you're seeing?

It's indeed not returned to the OS (as from previous discussion), which
is fine as soon as emacs can reuse the owned memory.
When I clear the image cache after closing every single image buffer,
emacs does seem to reuse the owned memory.
However, when the cache is cleared less frequently, it does not seem to
be the case - emacs just claims more memory from the system.
What I saw from my last test is that there is no significant difference
in the final memory consumption if I don't clear the image cache or
clear it every 5 seconds (around every 10-20 opened/killed images).

Best,
Ihor

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Ihor Radchenko <yantar92 <at> gmail.com> writes:
>
>> It appears to me that clearing image cache has some problem when there
>> is a relatively large number of images in the cache already.
>
> When Emacs frees memory, it's not normally returned to the OS.  Is that
> what you're seeing?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 15:11:01 GMT) Full text and rfc822 format available.

Message #62 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 28 Nov 2019 17:10:43 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 38345 <at> debbugs.gnu.org
> Date: Thu, 28 Nov 2019 09:38:34 +0800
> 
> #+begin_sec emacs-lisp
> (dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
>   (find-file file)
>   (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
>   (garbage-collect)
>   (clear-image-cache t))
> #+end_src
> 
> The resulting memory consumption graph is attached.
> The memory increase almost disappeared (remaining heap size becomes
> ~40Mb in comparison ~400Mb in the version with just garbage collect).
> 
> Just calling (clear-image-cache) after cycling over opening/killing
> the image buffers still results in ~400Mb (it has no effect, basically).
> 
> The above result is confusing since the all the code I tried to run so
> far had (setq image-cache-eviction-delay 5). Since, cycling over all the
> images usually took >1min, cache clearing supposed to happen at least
> several times during opening/killing the image buffers.

As I explained elsewhere, unless you call clear-image-cache from Lisp,
the only place we do that automatically is when the number of
redisplay cycles since last time the image cache was cleared becomes
greater than 101.  This, no matter how low is the value of
image-cache-eviction-delay, it will have no effect until we've done
101 redisplay cycles.  And your loop above does just one.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 17:30:02 GMT) Full text and rfc822 format available.

Message #65 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Fri, 29 Nov 2019 01:27:39 +0800
[Message part 1 (text/plain, inline)]
> As I explained elsewhere, unless you call clear-image-cache from Lisp,
> the only place we do that automatically is when the number of
> redisplay cycles since last time the image cache was cleared becomes
> greater than 101.  This, no matter how low is the value of
> image-cache-eviction-delay, it will have no effect until we've done
> 101 redisplay cycles.  And your loop above does just one.

Hmm. I saw that email, but did not understand it well. I thought that
cache clearing is triggered not later than image-cache-eviction-delay,
but can be triggered earlier if the number of cycles is more than 101...

The behaviour you describe does not follow the docstring:
> "*Maximum time* after which images are removed from the cache.
> ...
> If the cache contains
> a large number of images, the actual eviction time may be shorter.
> ...

Also, I repeated my tests manually calling image-clear-cache every Nth
image. Every invocation of image-clear-cache does reduce the memory
consumption, but there is always some residual remaining unrealeased
(see the attached images). The residual seems to scale with the number
of images in the cache before clearing.
Suggestion: we may be able to control the memory consumption if the
image-clear-cache is not only triggered by the time and display cycles,
but also by the cache size. If a variable like image-cache-max-size is
exposed to elisp, the user may be able to deal with similar memory
consumption issues just by reducing the variable value.
Though, indeed, there should be no residual memory in ideal scenario. 

Regards,
Ihor

[images-seq-2ndclear.png (image/png, attachment)]
[images-seq-10thclear.png (image/png, attachment)]
[images-seq-50thclear.png (image/png, attachment)]
[images-seq-100thclear.png (image/png, attachment)]
[Message part 6 (text/plain, inline)]



Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 38345 <at> debbugs.gnu.org
>> Date: Thu, 28 Nov 2019 09:38:34 +0800
>> 
>> #+begin_sec emacs-lisp
>> (dolist (file (directory-files "~/Tosort/pictures&photos/" 'full ".*jpg"))
>>   (find-file file)
>>   (mapc #'kill-buffer (seq-filter (apply-partially #'string-match ".+.jpg$") (mapcar #'buffer-name (buffer-list))))
>>   (garbage-collect)
>>   (clear-image-cache t))
>> #+end_src
>> 
>> The resulting memory consumption graph is attached.
>> The memory increase almost disappeared (remaining heap size becomes
>> ~40Mb in comparison ~400Mb in the version with just garbage collect).
>> 
>> Just calling (clear-image-cache) after cycling over opening/killing
>> the image buffers still results in ~400Mb (it has no effect, basically).
>> 
>> The above result is confusing since the all the code I tried to run so
>> far had (setq image-cache-eviction-delay 5). Since, cycling over all the
>> images usually took >1min, cache clearing supposed to happen at least
>> several times during opening/killing the image buffers.
>
> As I explained elsewhere, unless you call clear-image-cache from Lisp,
> the only place we do that automatically is when the number of
> redisplay cycles since last time the image cache was cleared becomes
> greater than 101.  This, no matter how low is the value of
> image-cache-eviction-delay, it will have no effect until we've done
> 101 redisplay cycles.  And your loop above does just one.


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 28 Nov 2019 18:45:02 GMT) Full text and rfc822 format available.

Message #68 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 28 Nov 2019 20:44:14 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
> Date: Fri, 29 Nov 2019 01:27:39 +0800
> 
> The behaviour you describe does not follow the docstring:
> > "*Maximum time* after which images are removed from the cache.
> > ...
> > If the cache contains
> > a large number of images, the actual eviction time may be shorter.
> > ...

The doc string assumes "normal" operation, it doesn't assume some Lisp
command runs for a long time, thus preventing redisplay.

> Also, I repeated my tests manually calling image-clear-cache every Nth
> image. Every invocation of image-clear-cache does reduce the memory
> consumption, but there is always some residual remaining unrealeased
> (see the attached images). The residual seems to scale with the number
> of images in the cache before clearing.

I think that's a simple result of how clear-image-cache is
implemented, I suggest to read the code.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 02 Dec 2019 08:07:02 GMT) Full text and rfc822 format available.

Message #71 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 02 Dec 2019 16:04:46 +0800
[Message part 1 (text/plain, inline)]
> The doc string assumes "normal" operation, it doesn't assume some Lisp
> command runs for a long time, thus preventing redisplay.

Sounds counter-intuitive. Elisp commands can run for a long time
(pointing at org-agenda). 

> I think that's a simple result of how clear-image-cache is
> implemented, I suggest to read the code.

I tried to look at the code, but I have to admit that I don't understand
the reason. Probably because of my poor C. 

In any case, I tried different approach trying to reduce memory
fragmentation. Instead of using the default malloc/free, I used jemalloc
through LD_PRELOAD. For periodic cache clearing (every 2,10,50, and 100
opened/killed images), there was no noticeable difference in the memory
consumption. However, when I tried to open a bunch of images all
together, killed them, and cleared the cache (as in my initial bug
report), the jemalloc instance of emacs showed much lower memory
consumption (~240Mb vs 1200Mb). 

The 240Mb is still higher in comparison with the memory consumption at
init, but a lot more manageable. So, I will try running emacs with
jemalloc for my main emacs instance and see if I am still getting the
high memory consumption in my workflow. 
Not sure if it is feasible to consider changing the memory allocator
upstream. Though large heap size might slow down garbage-collect (as
from discussion in
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01137.html)
and any means of reducing the heap may also help responsiveness of
emacs. 

The relevant memory graphs are attached (note that I had a lot of noise in
the previous graphs. It was because of two instances of emacs running at
the same time).

Regards,
Ihor

[images-new.png (image/png, attachment)]
[images-jemalloc.png (image/png, attachment)]
[Message part 4 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
>> Date: Fri, 29 Nov 2019 01:27:39 +0800
>> 
>> The behaviour you describe does not follow the docstring:
>> > "*Maximum time* after which images are removed from the cache.
>> > ...
>> > If the cache contains
>> > a large number of images, the actual eviction time may be shorter.
>> > ...
>
> The doc string assumes "normal" operation, it doesn't assume some Lisp
> command runs for a long time, thus preventing redisplay.
>
>> Also, I repeated my tests manually calling image-clear-cache every Nth
>> image. Every invocation of image-clear-cache does reduce the memory
>> consumption, but there is always some residual remaining unrealeased
>> (see the attached images). The residual seems to scale with the number
>> of images in the cache before clearing.
>
> I think that's a simple result of how clear-image-cache is
> implemented, I suggest to read the code.


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 02 Dec 2019 15:50:01 GMT) Full text and rfc822 format available.

Message #74 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 02 Dec 2019 17:49:30 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
> Date: Mon, 02 Dec 2019 16:04:46 +0800
> 
> > The doc string assumes "normal" operation, it doesn't assume some Lisp
> > command runs for a long time, thus preventing redisplay.
> 
> Sounds counter-intuitive. Elisp commands can run for a long time
> (pointing at org-agenda). 

Commands that run for a long time make Emacs unresponsive, and
therefore are a misfeature or a bug.

That said, a command that runs a long time is unlikely to create many
images, destroying each one before creating the next one, because
what would be the point of that?

IOW, yours is a scenario that is infrequent at best, IMO.

> I tried to look at the code, but I have to admit that I don't understand
> the reason. Probably because of my poor C. 

Feel free to ask questions about the details you don't understand.

> In any case, I tried different approach trying to reduce memory
> fragmentation. Instead of using the default malloc/free, I used jemalloc
> through LD_PRELOAD. For periodic cache clearing (every 2,10,50, and 100
> opened/killed images), there was no noticeable difference in the memory
> consumption. However, when I tried to open a bunch of images all
> together, killed them, and cleared the cache (as in my initial bug
> report), the jemalloc instance of emacs showed much lower memory
> consumption (~240Mb vs 1200Mb). 

I don't think replacing the system malloc on GNU/Linux systems (let
alone on others) is an idea we'd like to pursue.  You may have more
luck playing with mallopt calls in init_alloc_once_for_pdumper
(assuming your build defines DOUG_LEA_MALLOC).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 05 Dec 2019 06:51:03 GMT) Full text and rfc822 format available.

Message #77 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 05 Dec 2019 14:48:03 +0800
> Feel free to ask questions about the details you don't understand.

I tried to figure out why the memory consumption is increasing with less
frequent cache clearing.
As I understand, there may be two general reasons of this:
1. Increasing of memory used by the image cache data structure
2. Imperfect implementation of xfree or img->type->free, which are
called by free_image

xfree and img->type->free seem to rely on system libraries and are
unlikely to have such a noticeable memory leaks. 

For the image cache data structure, I can only see one place where it
may request extra memory allocation. It is when the number of images in
the cache exceeds the size of c->images array (= c->size, which is 50 by
default). I observed memory consumption increase even when the frequency
of cache clearing in my test was <50, which makes it unclear for me
where the extra memory consumption is coming from.

> I don't think replacing the system malloc on GNU/Linux systems (let
> alone on others) is an idea we'd like to pursue.  You may have more
> luck playing with mallopt calls in init_alloc_once_for_pdumper
> (assuming your build defines DOUG_LEA_MALLOC).

Do I understand correctly that you refer to emacs compiled with
alternative Doug Lea's implementation of malloc?

Actually, I tried to find a way to compile emacs with alternative
variants of malloc, but I did not find how to do it. 

P.S. I am running emacs with jemalloc for a few days and the overall
impression is that emacs became a lot more responsive. Previously, I
had a slow overtime degradation of delay between commands as emacs
process ran for a long time, up to the point when I can type a whole
sentence until emacs finally displays it on screen. Now, I do not see so
much degradation. 

Best,
Ihor


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
>> Date: Mon, 02 Dec 2019 16:04:46 +0800
>> 
>> > The doc string assumes "normal" operation, it doesn't assume some Lisp
>> > command runs for a long time, thus preventing redisplay.
>> 
>> Sounds counter-intuitive. Elisp commands can run for a long time
>> (pointing at org-agenda). 
>
> Commands that run for a long time make Emacs unresponsive, and
> therefore are a misfeature or a bug.
>
> That said, a command that runs a long time is unlikely to create many
> images, destroying each one before creating the next one, because
> what would be the point of that?
>
> IOW, yours is a scenario that is infrequent at best, IMO.
>
>> I tried to look at the code, but I have to admit that I don't understand
>> the reason. Probably because of my poor C. 
>
> Feel free to ask questions about the details you don't understand.
>
>> In any case, I tried different approach trying to reduce memory
>> fragmentation. Instead of using the default malloc/free, I used jemalloc
>> through LD_PRELOAD. For periodic cache clearing (every 2,10,50, and 100
>> opened/killed images), there was no noticeable difference in the memory
>> consumption. However, when I tried to open a bunch of images all
>> together, killed them, and cleared the cache (as in my initial bug
>> report), the jemalloc instance of emacs showed much lower memory
>> consumption (~240Mb vs 1200Mb). 
>
> I don't think replacing the system malloc on GNU/Linux systems (let
> alone on others) is an idea we'd like to pursue.  You may have more
> luck playing with mallopt calls in init_alloc_once_for_pdumper
> (assuming your build defines DOUG_LEA_MALLOC).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Thu, 05 Dec 2019 14:53:01 GMT) Full text and rfc822 format available.

Message #80 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Thu, 05 Dec 2019 16:52:33 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
> Date: Thu, 05 Dec 2019 14:48:03 +0800
> 
> For the image cache data structure, I can only see one place where it
> may request extra memory allocation. It is when the number of images in
> the cache exceeds the size of c->images array (= c->size, which is 50 by
> default). I observed memory consumption increase even when the frequency
> of cache clearing in my test was <50, which makes it unclear for me
> where the extra memory consumption is coming from.

What you describe is the situation where Emacs enlarges the image
cache because the existing cache can no longer hold all the images we
currently know about.  This is normal, and cannot cause a leak.

The suggestion in this discussion was to expunge images from the cache
more aggressively, and I thought you had difficulties in understand
how this is done currently.

> > I don't think replacing the system malloc on GNU/Linux systems (let
> > alone on others) is an idea we'd like to pursue.  You may have more
> > luck playing with mallopt calls in init_alloc_once_for_pdumper
> > (assuming your build defines DOUG_LEA_MALLOC).
> 
> Do I understand correctly that you refer to emacs compiled with
> alternative Doug Lea's implementation of malloc?

No.  AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC.

> Actually, I tried to find a way to compile emacs with alternative
> variants of malloc, but I did not find how to do it. 

I don't think we support it, at least not easily.

> P.S. I am running emacs with jemalloc for a few days and the overall
> impression is that emacs became a lot more responsive. Previously, I
> had a slow overtime degradation of delay between commands as emacs
> process ran for a long time, up to the point when I can type a whole
> sentence until emacs finally displays it on screen. Now, I do not see so
> much degradation. 

This has got to be a separate issue, perhaps related to GC (do you
have customizations of any GC-related variables?).  It should be
reported and analyzed separately, as it is unrelated to image caching.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Fri, 06 Dec 2019 01:35:01 GMT) Full text and rfc822 format available.

Message #83 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> gmail.com>, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Thu, 05 Dec 2019 20:34:31 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

> No.  AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC.

That's not the case with modern glibc, hence all that trouble with
ralloc, etc during Emacs 25.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Fri, 06 Dec 2019 16:16:02 GMT) Full text and rfc822 format available.

Message #86 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: yantar92 <at> gmail.com, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Fri, 06 Dec 2019 09:52:38 +0200
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Ihor Radchenko <yantar92 <at> gmail.com>,  38345 <at> debbugs.gnu.org,  juri <at> linkov.net
> Date: Thu, 05 Dec 2019 20:34:31 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > No.  AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC.
> 
> That's not the case with modern glibc, hence all that trouble with
> ralloc, etc during Emacs 25.

I was judging by what I see on fencepost.gnu.org, but I guess that
isn't "modern" anymore.

So does this mean modern glibc has no knobs to tailor its behavior to
various needs, like set the threshold for using mmap, etc.?  IOW, no
more support for the likes of mallopt?  If so, perhaps the reports
about jemalloc's superior performance should be sent to glibc
developers, as they could have a proper advice for that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sun, 08 Dec 2019 03:24:02 GMT) Full text and rfc822 format available.

Message #89 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: yantar92 <at> gmail.com, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Sat, 07 Dec 2019 21:39:35 +0200
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: yantar92 <at> gmail.com,  38345 <at> debbugs.gnu.org,  juri <at> linkov.net
> Date: Sat, 07 Dec 2019 14:25:06 -0500
> 
> > So does this mean modern glibc has no knobs to tailor its behavior to
> > various needs, like set the threshold for using mmap, etc.?  IOW, no
> > more support for the likes of mallopt?
> 
> Looks like mallopt is still there, but Emacs' DOUG_LEA_MALLOC code
> depends on malloc_set_state and malloc_get_state which were removed in
> glibc 2.25 (2017).
> https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html

Thanks.  Then I don't understand why our calls to mallopt are
conditioned on DOUG_LEA_MALLOC.  What they are supposed to do should
be good for modern glibc versions as well.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sun, 08 Dec 2019 03:38:01 GMT) Full text and rfc822 format available.

Message #92 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> gmail.com, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50;
 Permanent increase in memory consumption after opening images (or
 pdfs)
Date: Sat, 07 Dec 2019 14:25:06 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> > No.  AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC.
>> 
>> That's not the case with modern glibc, hence all that trouble with
>> ralloc, etc during Emacs 25.
>
> I was judging by what I see on fencepost.gnu.org, but I guess that
> isn't "modern" anymore.

Yeah, it seems to have glibc 2.19 (released in 2014).

> So does this mean modern glibc has no knobs to tailor its behavior to
> various needs, like set the threshold for using mmap, etc.?  IOW, no
> more support for the likes of mallopt?

Looks like mallopt is still there, but Emacs' DOUG_LEA_MALLOC code
depends on malloc_set_state and malloc_get_state which were removed in
glibc 2.25 (2017).
https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 16 Dec 2019 06:22:01 GMT) Full text and rfc822 format available.

Message #95 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 16 Dec 2019 14:18:58 +0800
> What you describe is the situation where Emacs enlarges the image
> cache because the existing cache can no longer hold all the images we
> currently know about.  This is normal, and cannot cause a leak.

Agree. 

In my earlier email, it described my trial to expunge the images from
cache more aggressively:

>> also, I repeated my tests manually calling image-clear-cache every Nth
>> image. Every invocation of image-clear-cache does reduce the memory
>> consumption, but there is always some residual remaining unrealeased
>> (see the attached images). The residual seems to scale with the number
>> of images in the cache before clearing.

You suggested to look at the C code.

However, looking at the C code, I don't understand then why the
memory consumption is increasing. I can only see that too many images in
c->images array can cause extra memory consumption, which cannot cause
the observed memory leak.

Do you have any idea why even aggressive cache clearing causes memory
consumption increase?

Best,
Ihor


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
>> Date: Thu, 05 Dec 2019 14:48:03 +0800
>> 
>> For the image cache data structure, I can only see one place where it
>> may request extra memory allocation. It is when the number of images in
>> the cache exceeds the size of c->images array (= c->size, which is 50 by
>> default). I observed memory consumption increase even when the frequency
>> of cache clearing in my test was <50, which makes it unclear for me
>> where the extra memory consumption is coming from.
>
> What you describe is the situation where Emacs enlarges the image
> cache because the existing cache can no longer hold all the images we
> currently know about.  This is normal, and cannot cause a leak.
>
> The suggestion in this discussion was to expunge images from the cache
> more aggressively, and I thought you had difficulties in understand
> how this is done currently.
>
>> > I don't think replacing the system malloc on GNU/Linux systems (let
>> > alone on others) is an idea we'd like to pursue.  You may have more
>> > luck playing with mallopt calls in init_alloc_once_for_pdumper
>> > (assuming your build defines DOUG_LEA_MALLOC).
>> 
>> Do I understand correctly that you refer to emacs compiled with
>> alternative Doug Lea's implementation of malloc?
>
> No.  AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC.
>
>> Actually, I tried to find a way to compile emacs with alternative
>> variants of malloc, but I did not find how to do it. 
>
> I don't think we support it, at least not easily.
>
>> P.S. I am running emacs with jemalloc for a few days and the overall
>> impression is that emacs became a lot more responsive. Previously, I
>> had a slow overtime degradation of delay between commands as emacs
>> process ran for a long time, up to the point when I can type a whole
>> sentence until emacs finally displays it on screen. Now, I do not see so
>> much degradation. 
>
> This has got to be a separate issue, perhaps related to GC (do you
> have customizations of any GC-related variables?).  It should be
> reported and analyzed separately, as it is unrelated to image caching.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 16 Dec 2019 16:31:02 GMT) Full text and rfc822 format available.

Message #98 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 16 Dec 2019 18:30:07 +0200
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: juri <at> linkov.net, 38345 <at> debbugs.gnu.org
> Date: Mon, 16 Dec 2019 14:18:58 +0800
> 
> In my earlier email, it described my trial to expunge the images from
> cache more aggressively:
> 
> >> also, I repeated my tests manually calling image-clear-cache every Nth
> >> image. Every invocation of image-clear-cache does reduce the memory
> >> consumption, but there is always some residual remaining unrealeased
> >> (see the attached images). The residual seems to scale with the number
> >> of images in the cache before clearing.
> 
> You suggested to look at the C code.
> 
> However, looking at the C code, I don't understand then why the
> memory consumption is increasing. I can only see that too many images in
> c->images array can cause extra memory consumption, which cannot cause
> the observed memory leak.

I guess that's because the freed memory is not at the end of the heap,
and this cannot be returned to the OS.

> Do you have any idea why even aggressive cache clearing causes memory
> consumption increase?

See above.  You are talking about "memory consumption", but actually
you trace the memory address space allocated to the Emacs process, and
that includes memory we freed, but the underlying C library couldn't
return back to the OS.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sun, 02 Aug 2020 18:15:01 GMT) Full text and rfc822 format available.

Message #101 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> gmail.com>, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Sun, 02 Aug 2020 20:14:29 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> However, looking at the C code, I don't understand then why the
>> memory consumption is increasing. I can only see that too many images in
>> c->images array can cause extra memory consumption, which cannot cause
>> the observed memory leak.
>
> I guess that's because the freed memory is not at the end of the heap,
> and this cannot be returned to the OS.

This was half a year ago, and skimming this bug report, it seems like
this was the tentative conclusion -- there's no memory leak, just the
allocator not returning the memory back to the OS.

If that's the case, then this bug report can be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Sun, 02 Aug 2020 22:54:01 GMT) Full text and rfc822 format available.

Message #104 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 03 Aug 2020 06:52:15 +0800
> If that's the case, then this bug report can be closed?

I think so.

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> However, looking at the C code, I don't understand then why the
>>> memory consumption is increasing. I can only see that too many images in
>>> c->images array can cause extra memory consumption, which cannot cause
>>> the observed memory leak.
>>
>> I guess that's because the freed memory is not at the end of the heap,
>> and this cannot be returned to the OS.
>
> This was half a year ago, and skimming this bug report, it seems like
> this was the tentative conclusion -- there's no memory leak, just the
> allocator not returning the memory back to the OS.
>
> If that's the case, then this bug report can be closed?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92 <at> gmail.com, ihor_radchenko <at> alumni.sutd.edu.sg




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38345; Package emacs. (Mon, 03 Aug 2020 06:12:01 GMT) Full text and rfc822 format available.

Message #107 received at 38345 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38345 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#38345: 27.0.50; Permanent increase in memory consumption
 after opening images (or pdfs)
Date: Mon, 03 Aug 2020 08:10:57 +0200
Ihor Radchenko <yantar92 <at> gmail.com> writes:

>> If that's the case, then this bug report can be closed?
>
> I think so.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 03 Aug 2020 06:12:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 38345 <at> debbugs.gnu.org and Ihor Radchenko <yantar92 <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 03 Aug 2020 06:12:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 31 Aug 2020 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 209 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.