> 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
> 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
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 except for having some memory leaks
somewhere. Simplified version of the R app:
while (TRUE) {
c
Hello,
## Configuring R with
./configure --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh
--with-tk-config=/usr/lib/tk8.5/tkConfig.sh CFLAGS="-fsanitize=address
-fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr "
CXXFLAGS="-fsanitize=address -fsanitize=undefined
-fno-sanitize=float-d
Hi,
I have a problem with a large data set wrapped in a reference class. I do that
to access the data by reference from within various functions in a script.
# The class definition:
setRefClass("data",
fields = list(h5_df= "list",
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
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 VIRT RES SHR S %CPU %MEMTIME+ COMMAND
6637 darstr20
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
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 in the regular expression:
% R --debugger=valgrind --debugger-args=--leak-check=fu
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>
Several folks have previously written that valgrind notices
a memory leak in R's readline code. It looks like it leaks
a copy of every input line.
% ~/R-svn/r-devel/R/bin/R --debugger=valgrind --debugger-args=--leak-check=full
--vanilla
==10725== Memcheck, a memory error detector.
==10725== Copy
There is a 2-block memory leak in the sub() (or any other regex-related
function, probably) when the pattern argument involves a range
expression, e.g., '[0-9]'.
% R --debugger=valgrind --debugger-args=--leak-check=full --vanilla
==14519== Memcheck, a memory error detector.
==14519== Copyright (C)
Hello,
To trigger the memory leak, an application embedding R will have printed
a vector element of size R_BUFSIZE or more to stdout, so long as the
R_Outputfile pointer is NULL and R was compiled with vasprintf support.
The leak is in Rcons_vprintf from printutils.c. It looks as though
some
This is a followup to the R-help thread, "Error: STRING_ELT() can only
be applied to a 'character vector', not a 'builtin'". Thanks to Prof.
Brian Ripley for suggesting the use of gctorture and valgrind. I am
getting segmentation faults that appear to come from a memory leak.
I now have a reprod
27 matches
Mail list logo
