> Tim Taylor
> on Tue, 17 Jan 2023 13:39:01 + writes:
> On 17/01/2023 13:06, Duncan Murdoch wrote:
>> I don't have a valgrind-capable version of R, but I'd be interested to
>> see whether this is a one-time loss, or repeated. That is, do you get a
>> much bigger
On 17/01/2023 13:06, Duncan Murdoch wrote:
I don't have a valgrind-capable version of R, but I'd be interested to
see whether this is a one-time loss, or repeated. That is, do you get a
much bigger loss from running the lossy code in a loop like this?
for (i in 1:100) { png(filename='p.png'
I don't have a valgrind-capable version of R, but I'd be interested to
see whether this is a one-time loss, or repeated. That is, do you get a
much bigger loss from running the lossy code in a loop like this?
for (i in 1:100) { png(filename='p.png'); plot(1:10); dev.off() }
Duncan Murdoch
Note that cairo_pdf() also suffers from the same leak
.. as to be expected once you notice that much of the cairo
device handling uses common code.
...
.. and then, when you are aware that on Linux, the default
interactive device is x11() and its default type is *also*
"cairo" { possibly not on
> Edward Ionides
> on Mon, 16 Jan 2023 09:04:49 -0500 writes:
> Hi all,
> Yesterday I discovered what seems to me like a memory leak in png() so I'm
> reporting it in case that is helpful. Here is a small reproducible
example:
> R -d "valgrind --tool=memcheck --trac
Hi all,
Yesterday I discovered what seems to me like a memory leak in png() so I'm
reporting it in case that is helpful. Here is a small reproducible example:
R -d "valgrind --tool=memcheck --track-origins=yes --leak-check=full"
--vanilla -e "png(filename='p.png'); plot(1:10); dev.off()"
## HAS L
