> 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
> Gábor Csárdi
> on Sun, 13 Nov 2016 20:49:57 + writes:
> Using dup() before fdopen() (and calling fclose() on the connection
> when it is closed) indeed fixes the memory leak.
>
Thank you, Gábor!
Yes I can confirm that this fixes the memory leak.
I'm testing ('make check-all')
Using dup() before fdopen() (and calling fclose() on the connection
when it is closed) indeed fixes the memory leak.
FYI,
Gabor
Index: src/main/connections.c
===
--- src/main/connections.c (revision 71653)
+++ src/main/connections.c
On Fri, Nov 11, 2016 at 12:46 PM, Gergely Daróczi
wrote:
[...]
>> I've changed the above to *print* the gc() result every 1000th
>> iteration, and after 100'000 iterations, there is still no
>> memory increase from the point of view of R itself.
Yes, R does not know about it, it does not manage t
On Fri, Nov 11, 2016 at 12:08 PM, Martin Maechler
wrote:
>> Gergely Daróczi
>> on Thu, 10 Nov 2016 16:48:12 +0100 writes:
>
> > Dear All,
> > I'm developing an R application running inside of a Java daemon on
> > multiple threads, and interacting with the parent daemon via
> Gergely Daróczi
> on Thu, 10 Nov 2016 16:48:12 +0100 writes:
> Dear All,
> I'm developing an R application running inside of a Java daemon on
> multiple threads, and interacting with the parent daemon via stdin and
> stdout.
> Everything works perfectly fine exc
Hello again,
Thanks, that explanation helps me understand the issue more. My platform is
Platform: x86_64-unknown-linux-gnu (64-bit) (Ubuntu 10.04 to be more precise).
- Dario.
Original message
>Date: Tue, 1 Feb 2011 21:29:38 -0500
>From: Simon Urbanek
>Subject: Re: [R
On Feb 1, 2011, at 9:00 PM, Dario Strbenac wrote:
> Hello,
>
> I'm trying to track down the cause of some extreme memory usage and I've been
> using Dirk Eddelbuettel's lsos() function he posted on stack overflow. There
> is a large difference between R's RAM usage :
>
> PID USER PR NI
For the record: this is now fixed.
On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote:
> Full_Name: Bill Dunlap
> Version: R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
> OS: Linux
> Submission from: (NULL) (76.28.245.14)
>
>
> valgrind finds some memory leaks in R when I use sub() wi
For the record: this is now fixed.
On Thu, 7 Aug 2008, [EMAIL PROTECTED] wrote:
Full_Name: Bill Dunlap
Version: R version 2.8.0 Under development (unstable) (2008-07-05 r46037)
OS: Linux
Submission from: (NULL) (76.28.245.14)
valgrind finds some memory leaks in R when I use sub() with
a range
As a belated follow-up (I was away at the time), note that in general we
don't tamper with code we have ported from other projects as it makes
future maintenance so much more difficult. At the very least, we need
conspicuous comments to ensure that such changes do not get lost (I've
just added
> "BD" == Bill Dunlap <[EMAIL PROTECTED]>
> on Thu, 10 Jul 2008 13:17:03 -0700 (PDT) writes:
BD> Several folks have previously written that valgrind
BD> notices a memory leak in R's readline code. It looks
BD> like it leaks a copy of every input line.
[]
Than
> "BD" == Bill Dunlap <[EMAIL PROTECTED]>
> on Wed, 9 Jul 2008 11:26:50 -0700 (PDT) writes:
BD> There is a 2-block memory leak in the sub() (or any other regex-related
BD> function, probably) when the pattern argument involves a range
BD> expression, e.g., '[0-9]'.
BD>
17 matches
Mail list logo
