[Rd] ylim (PR#13753)
Full_Name: R User
Version: 2.9
OS: All
Submission from: (NULL) (18.26.0.5)
Add xlim and ylim to 'par' documentation page.
> help.search("ylim")
No help files found with alias or concept or title matching ylim
using regular expression matching.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Can't get F77_CALL(dgemm) to work [SEC=UNCLASSIFIED]
Hi
I am new to writing C code and am trying to write an R extension in C. I
have hit a wall with F77_CALL(dgemm) in that it produces wrong results.
The code below is a simplified example that multiplies the matrices Ab and
Bm to give Cm. The results below show clearly that Cm is wrong.
Am=
1 234
5 678
9 10 11 12
13 14 15 16
17 18 19 20
Bm=
1 1 1
1 1 1
1 1 1
1 1 1
Cm=
34 38 42
46 50 34
38 42 46
50 34 38
42 46 50
I have searched the internet and suspect it has something to do with column
major matrix format for Fortran being inconsistent with the row major
format for C but I'm not sure how to fix this in C. One suggestion I came
across (http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=915) is to
use cblas_dgemm in which the option 'CblasColMajor' can be specified.
However, I would have thought that F77_CALL(dgemm) should work as it has
been used in some R packages. I'm also not sure that cblas would work from
R.
I tried inputting matrices into dgemm as 2 dimensional arrays and as one
dimensional arrays. However the results for Cm were the same in both
cases.
Any help would be much appreciated.
Cheers
Daniel
C Code
#include
#include
#include
#include
#include "math.h"
#define BLAS_H
#include "MPQL.h"
#include
void MPQL(int *iterations) {
double **Am;
double *Am_vec;
double **Bm;
double *Bm_vec;
double **Cm;
double *Cm_vec;
double one = 1.0;
double zero = 0.0;
int j, r, c;
int rows_A =5;
int cols_A =4;
int rows_B =4;
int cols_B =3;
int rows_C =5;
int cols_C =3;
Am= Calloc(rows_A,double *);
Am_vec= Calloc(rows_A*cols_A,double);
Bm= Calloc(rows_B,double *);
Bm_vec= Calloc(rows_B*cols_B,double);
Cm= Calloc(rows_C,double *);
Cm_vec= Calloc(rows_C*cols_C,double);
for (j = 0; j < rows_A; j++) Am[j] = Am_vec + j * cols_A;
for (j = 0; j < rows_B; j++) Bm[j] = Bm_vec + j * cols_B;
for (j = 0; j < rows_C; j++) Cm[j] = Cm_vec + j * cols_C;
for (r = 0; r < rows_A; r++)
for (c = 0; c < cols_A; c++)
{
Am[r][c] = r*(cols_A) + c + 1.0;
};
for (r = 0; r < rows_B; r++)
for (c = 0; c < cols_B; c++)
Bm[r][c] = 1.0;
Rprintf("\n\n Am= \n");
for (r = 0; r < rows_A; r++)
for (c = 0; c < cols_A; c++)
if (c==(cols_A - 1)) Rprintf("%2.0f \n" ,(double) Am[r][c]);
else
Rprintf("%2.0f ",(double) Am[r][c]);
Rprintf("\n\n Am_vec= \n"); for (r = 0; r < (rows_A * cols_A); r++)
Rprintf("%2.0f " ,(double) Am_vec[r]);
Rprintf("\n\n Bm=\n");
for (r = 0; r < rows_B; r++)
for (c = 0; c < cols_B; c++)
if (c==(cols_B-1)) Rprintf("%2.0f \n" ,(double) Bm[r][c]); else
Rprintf("%2.0f ",(double) Bm[r][c]);
Rprintf("\n\n Bm_vec= \n"); for (r = 0; r < (rows_B * cols_B); r++)
Rprintf("%2.0f " ,(double) Bm_vec[r]);
/* Inputting matrices as 2 dimensional arrays gives same results as one
dimensional form below
F77_CALL(dgemm)("N", "N", &rows_A, &cols_B, &cols_A, &one, *Am, &rows_A,
*Bm, &rows_B, &zero, *Cm, &rows_C);
*/
F77_CALL(dgemm)("N", "N", &rows_A, &cols_B, &cols_A, &one, Am_vec, &rows_A,
Bm_vec, &rows_B, &zero, Cm_vec, &rows_C);
Rprintf("\n\n Cm=\n");
for (r = 0; r < rows_C; r++)
for (c = 0; c < cols_C; c++)
if (c==(cols_C-1)) Rprintf("%2.0f \n" ,(double) Cm[r][c]); else
Rprintf("%2.0f ",(double) Cm[r][c]);
Rprintf("\n\n Cm_vec= \n"); for (r = 0; r < (rows_C * cols_C); r++)
Rprintf("%2.0f " ,(double) Cm_vec[r]);
Free(Cm_vec);
Free(Cm);
Free(Bm_vec);
Free(Bm);
Free(Am_vec);
Free(Am);
}
Header File
/* C:\Data\RPackages\MPQL\src\MPQL.h */
#include
/* #include */
void MPQL (int *iterations);
R File compiled with C code above
MPQL <- function(iterations){
Result <- .C("MPQL",
as.integer(iterations),
DUP = TRUE,
PACKAGE = "MPQL"
)
}
R code to call the compiled C dll
rm(list = ls(all = TRUE))
gc()
# Load R packages.
library(reshape)
library(MPQL)
SAE.MPQL <- function(its) {
MPQL.object <- MPQL(its)
}
BOTT <- SAE.MPQL(its=2)
Free publications and statistics available on www.abs.gov.au
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ylim (PR#13753)
anonru...@mit.edu wrote:
Full_Name: R User
Version: 2.9
OS: All
Submission from: (NULL) (18.26.0.5)
Add xlim and ylim to 'par' documentation page.
Does not make sense, since it's not an argument to par():
> par("xlim"=c(0,1))
Warning message:
In par(xlim = c(0, 1)) : "xlim" is not a graphical parameter
But ?par links prominently to ?plot.default which explains them.
Uwe Ligges
help.search("ylim")
No help files found with alias or concept or title matching ‘ylim’
using regular expression matching.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Rhistory created with wrong permissions (PR#13752)
Prof Brian Ripley wrote: Yes, it is by design, and not R's design at that. How (or if) the history is saved is determined by the GUI interface in use. In this case it appears to be command-line R built with readline support, in which case the saving is done by readline's write_history. And although the history.info manual does not say so, it does open files with pemissions 0600 (and there is no provison to change this). OK, undocumented feature of a library R links to. Thanks for explaining. To claim 'wrong permissions' implies that you 'know for certain' what the permissions should be -- I don't now how you can know them unless you can point to documentation that asserts the correct value as something different. Woah! No need to get snappy or pedantic. There's no documentation one way or the other, so "wrong" has to be relative to standard procedure. There's no documentation saying R doesn't "rm -rf /" on full moons, but one still expects that it doesn't. Most programs create files 0666 modified by umask, except if there's a good reason to restrict things. 0666 is also what fopen does when creating a file. Furthermore .RData is created 0666, and I didn't think a user's history was more sensitive than his data, so I thought .Rhistory should be 0666 as well. Paul's answer about passwords clears that up. OK, I should have written "unusual permissions". And I realize now that I should have posted to r-devel instead of submitting a bug. Sorry for the noise, I'm new to R. Regards, Nicolas Thierry-Mieg On Wed, 10 Jun 2009, Paul Gilbert wrote: nicolas.thierry-m...@imag.fr wrote: Hi, This is with a centos 5.3 x86_64 system, using R 2.8.1 (details below). In a directory where R is invoked, at the end of a session R offers to "Save workspace image". Replying yes creates/updates at least two files in the current directory: .Rhistory and .RData. .Rhistory is created with permissions 0600, therefore it effectively ignores umask. In particular, .Rhistory cannot be group-readable, which can be problematic in some environments. This is not the case for .RData (created 0666, modified by umask as usual), so I doubt that the .Rhistory permissions are restrictive by design? I`m not sure, but it may be by design. For example, users sometimes use passwords to connections, which one might not want accidentally recorded in a readable file. Paul If not, it would be better to create .Rhistory 0666 and let the user control the actual permissions through umask. Regards, Nicolas Thierry-Mieg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can't get F77_CALL(dgemm) to work [SEC=UNCLASSIFIED]
Daniel,
R apparently uses Fortran order AND storage method when
storing a matrix. For an (n x m) matrix, Fortran allocates
a single block of nm doubles and stores them in the order
A(1,1),A(2,1),A(3,1),...,A(n,1),A(1,2),A(2,2),...,A(n,m).
In contrast, C allocates a vector of n pointers, each pointing
to a row of the matrix, and then a vector of doubles of length
m for each row. This uses more storage space: nm doubles
and n pointers. Depending on how the matrix is defined, there
is no guarantee that the rows are consecutive memory. IF the
rows are in consecutive memory and you pass the address of
the first element to Fortran, it will "see" the transpose
of A, not A.
You can force them to be in consecutive memory by allocating
the whole block at once. It is not clear from the Writing
R extensions manual how Calloc allocates. The function
dmatrix that is in the free C routines nrutil.c from the
Numerical Recipes books deliberately allocates a block.
Another way to deal with this is to write short routines
to explicitly copy one form of matrix to the other. This
takes more memory and is a bit slower, but safer and works
in all cases. If anyone wants such code, let me know.
John
...
John P. Nolan
Math/Stat Department
227 Gray Hall
American University
4400 Massachusetts Avenue, NW
Washington, DC 20016-8050
jpno...@american.edu
202.885.3140 voice
202.885.3155 fax
http://academic2.american.edu/~jpnolan
...
-r-devel-boun...@r-project.org wrote: -
To: r-devel@r-project.org
From: Daniel Elazar
Sent by: r-devel-boun...@r-project.org
Date: 06/12/2009 03:03AM
Subject: [Rd] Can't get F77_CALL(dgemm) to work [SEC=UNCLASSIFIED]
Hi
I am new to writing C code and am trying to write an R extension in C. I
have hit a wall with F77_CALL(dgemm) in that it produces wrong results.
The code below is a simplified example that multiplies the matrices Ab and
Bm to give Cm. The results below show clearly that Cm is wrong.
Am=
1 234
5 678
9 10 11 12
13 14 15 16
17 18 19 20
Bm=
1 1 1
1 1 1
1 1 1
1 1 1
Cm=
34 38 42
46 50 34
38 42 46
50 34 38
42 46 50
I have searched the internet and suspect it has something to do with column
major matrix format for Fortran being inconsistent with the row major
format for C but I'm not sure how to fix this in C. One suggestion I came
across (http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=915) is to
use cblas_dgemm in which the option 'CblasColMajor' can be specified.
However, I would have thought that F77_CALL(dgemm) should work as it has
been used in some R packages. I'm also not sure that cblas would work from
R.
I tried inputting matrices into dgemm as 2 dimensional arrays and as one
dimensional arrays. However the results for Cm were the same in both
cases.
Any help would be much appreciated.
Cheers
Daniel
C Code
#include
#include
#include
#include
#include "math.h"
#define BLAS_H
#include "MPQL.h"
#include
void MPQL(int *iterations) {
double **Am;
double *Am_vec;
double **Bm;
double *Bm_vec;
double **Cm;
double *Cm_vec;
double one = 1.0;
double zero = 0.0;
int j, r, c;
int rows_A =5;
int cols_A =4;
int rows_B =4;
int cols_B =3;
int rows_C =5;
int cols_C =3;
Am= Calloc(rows_A,double *);
Am_vec= Calloc(rows_A*cols_A,double);
Bm= Calloc(rows_B,double *);
Bm_vec= Calloc(rows_B*cols_B,double);
Cm= Calloc(rows_C,double *);
Cm_vec= Calloc(rows_C*cols_C,double);
for (j = 0; j < rows_A; j++) Am[j] = Am_vec + j * cols_A;
for (j = 0; j < rows_B; j++) Bm[j] = Bm_vec + j * cols_B;
for (j = 0; j < rows_C; j++) Cm[j] = Cm_vec + j * cols_C;
for (r = 0; r < rows_A; r++)
for (c = 0; c < cols_A; c++)
{
Am[r][c] = r*(cols_A) + c + 1.0;
};
for (r = 0; r < rows_B; r++)
for (c = 0; c < cols_B; c++)
Bm[r][c] = 1.0;
Rprintf("\n\n Am= \n");
for (r = 0; r < rows_A; r++)
for (c = 0; c < cols_A; c++)
if (c==(cols_A - 1)) Rprintf("%2.0f \n" ,(double) Am[r][c]);
else
Rprintf("%2.0f ",(double) Am[r][c]);
Rprintf("\n\n Am_vec= \n"); for (r = 0; r < (rows_A * cols_A); r++)
Rprintf("%2.0f " ,(double) Am_vec[r]);
Rprintf("\n\n Bm=\n");
for (r = 0; r < rows_B; r++)
for (c = 0; c < cols_B; c++)
if (c==(cols_B-1)) Rprintf("%2.0f \n" ,(double) Bm[r][c]); else
Rprintf("%2.0f ",(double) Bm[r][c]);
Rprintf("\n\n Bm_vec= \n"); for (r = 0; r < (rows_B * cols_B); r++)
Rprintf("%2.0f " ,(double) Bm_vec[r]);
/* Inputting matrices as 2 dimensional arrays gives same results as one
dimensional form below
F77_CALL(dgemm)("N", "N", &rows_A, &cols_B, &cols_A, &one, *Am, &rows_A,
*Bm, &rows_B, &zero,
[Rd] bundle deprecation
Hi I read that bundles are to be deprecated in 2.10. The BACCO bundle contains three packages (emulator, calibrator, approximator) which I am happy to unbundle. But the 'BACCO' moniker has some considerable cachet for me in terms of recognizability (eg with grant-giving bodies), as it has become an umbrella term for a whole bunch of related statistical functionality of which the three packages are examples. I make heavy use of the word "BACCO" in my publications. If bundles were to be supported indefinitely, I would add further packages to the BACCO bundle from time to time and their relationship with the other packages would be clear. What is the best way to preserve the 'BACCO' name in a non-bundled world? Perhaps adding a 'FormerBundle' line in the DESCRIPTION file? best wishes Robin -- Robin K. S. Hankin Uncertainty Analyst University of Cambridge 19 Silver Street Cambridge CB3 9EP 01223-764877 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bundle deprecation
Perhaps you could have a package called BACCO
with no contents rather but lists the components of the
bundle as dependencies. Then package.install("BACCO")
would still install all the components.
On Fri, Jun 12, 2009 at 9:36 AM, Robin Hankin wrote:
> Hi
>
> I read that bundles are to be deprecated in 2.10.
>
> The BACCO bundle contains three packages
> (emulator, calibrator, approximator) which I
> am happy to unbundle.
>
> But the 'BACCO' moniker has some considerable
> cachet for me in terms of recognizability (eg
> with grant-giving bodies), as it has become an umbrella
> term for a whole bunch of related statistical
> functionality of which the three packages are examples.
>
> I make heavy use of the word "BACCO" in my publications.
>
> If bundles were to be supported indefinitely, I
> would add further packages to the BACCO
> bundle from time to time and their relationship
> with the other packages would be clear.
>
> What is the best way to preserve the 'BACCO'
> name in a non-bundled world?
>
> Perhaps adding a 'FormerBundle' line in the DESCRIPTION file?
>
>
> best wishes
>
> Robin
>
>
>
>
> --
> Robin K. S. Hankin
> Uncertainty Analyst
> University of Cambridge
> 19 Silver Street
> Cambridge CB3 9EP
> 01223-764877
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Fwd: Problem with tabbed notebook (tcltk, Iwidgets)]
--
Talita Perciano
Department of Computer Science - IME - USP
PhD Student in Computer Science
São Paulo, SP, Brazil
Tel: +55 11 8826 7092
--- Begin Message ---
Hi,
I'm using R version 2.9.0 and I'm trying to execute an example using
tabnotebook from iwidgets. Unfortunately I get a problem as you can see
bellow:
> library(tcltk)
Loading Tcl/Tk interface ... done
> library(tkrplot)
> tclRequire("Iwidgets")
4.0.1
>
> tt <- tktoplevel()
> tkpack(tn <- tkwidget(tt, "iwidgets::tabnotebook"))
*** caught segfault ***
address 0xffb8, cause 'memory not mapped'
Traceback:
1: .External("dotTclObjv", objv, PACKAGE = "tcltk")
2: structure(.External("dotTclObjv", objv, PACKAGE = "tcltk"), class =
"tclObj")
3: .Tcl.objv(.Tcl.args.objv(...))
4: tcl(type, win, ...)
5: tkwidget(tt, "iwidgets::tabnotebook")
6: .Tcl.args.objv(...)
7: structure(.External("dotTclObjv", objv, PACKAGE = "tcltk"), class =
"tclObj")
8: .Tcl.objv(.Tcl.args.objv(...))
9: tcl("pack", ...)
10: tkpack(tn <- tkwidget(tt, "iwidgets::tabnotebook"))
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: error in background error handler:
out of stack space (infinite loop?)
while executing
"::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0
-errorcode NONE -errorinfo {out of stack space (infinite loop?)
while execu..."
error in background error handler:
out of stack space (infinite loop?)
while executing
"::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0
-errorcode NONE -errorinfo {out of stack space (infinite loop?)
while execu..."
Anybody could help me?
Thanks,
Talita
--
Talita Perciano
Department of Computer Science - IME - USP
PhD Student in Computer Science
São Paulo, SP, Brazil
Tel: +55 11 8826 7092
--- End Message ---
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with tabbed notebook (tcltk, Iwidgets)
Hi,
I'm using R version 2.9.0 and I'm trying to execute an example using
tabnotebook from iwidgets. Unfortunately I get a problem as you can see
bellow:
> library(tcltk)
Loading Tcl/Tk interface ... done
> library(tkrplot)
> tclRequire("Iwidgets")
4.0.1
>
> tt <- tktoplevel()
> tkpack(tn <- tkwidget(tt, "iwidgets::tabnotebook"))
*** caught segfault ***
address 0xffb8, cause 'memory not mapped'
Traceback:
1: .External("dotTclObjv", objv, PACKAGE = "tcltk")
2: structure(.External("dotTclObjv", objv, PACKAGE = "tcltk"), class =
"tclObj")
3: .Tcl.objv(.Tcl.args.objv(...))
4: tcl(type, win, ...)
5: tkwidget(tt, "iwidgets::tabnotebook")
6: .Tcl.args.objv(...)
7: structure(.External("dotTclObjv", objv, PACKAGE = "tcltk"), class =
"tclObj")
8: .Tcl.objv(.Tcl.args.objv(...))
9: tcl("pack", ...)
10: tkpack(tn <- tkwidget(tt, "iwidgets::tabnotebook"))
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: error in background error handler:
out of stack space (infinite loop?)
while executing
"::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0
-errorcode NONE -errorinfo {out of stack space (infinite loop?)
while execu..."
error in background error handler:
out of stack space (infinite loop?)
while executing
"::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0
-errorcode NONE -errorinfo {out of stack space (infinite loop?)
while execu..."
Anybody could help me?
Thanks,
Talita
--
Talita Perciano
Department of Computer Science - IME - USP
PhD Student in Computer Science
São Paulo, SP, Brazil
Tel: +55 11 8826 7092
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formal argument "envir" matched by multiple actual arguments
On Tue, 2 Jun 2009, l...@stat.uiowa.edu wrote:
On Tue, 2 Jun 2009, Henrik Bengtsson wrote:
Nice case - I think you're onto something. /Henrik
2009/6/2 :
In fact reg.finalizer() looks like a dangerous feature.
If the finalizer itself triggers (implicitely or
explicitely) garbage collection, then bad things happen.
In the following example, garbage collection is triggered
explicitely (using R-2.9.0):
setClass("B", representation(bb="environment"))
newB <- function()
{
ans <- new("B", bb=new.env())
reg.finalizer(a...@bb,
function(e)
{
gc()
cat("cleaning", class(ans), "object...\n")
}
)
return(ans)
}
> for (i in 1:500) {cat(i, "\n"); b1 <- newB()}
1
2
3
4
5
6
...
13
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
14
...
169
170
171
Error: not a weak reference
Error: not a weak reference
[repeat the above line thousands of times]
...
Error: not a weak reference
Error: not a weak reference
cleaning B object...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
[repeat the above line thousands of times]
...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
172
...
246
247
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
*** caught segfault ***
address 0x41, cause 'memory not mapped'
Traceback:
1: gc()
2: function (e) { gc() cat("cleaning", class(ans),
"object...\n")}()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
Segmentation fault
So apparently, if the finalizer triggers garbage collection,
then we can end up with a corrupted session. Then anything can
happen, from the strange 'formal argument "envir" matched by
multiple actual arguments' error I reported in the previous post,
to a segfault. In the worse case, nothing apparently happens but
the output produced by the code is wrong.
Maybe garbage collection requests should be ignored during the
execution of the finalizer? (and more generally during garbbage
collection itself)
Thanks for the report. The gc proper does not (or should not) do
anything that could cause allocation or trigger another gc. The gc
proper only identifies objects ready for finalization; running the
finalizers happens outside the gc proper where allocation and gc calls
should be safe. This looks like either a missing PROTECT call in the
code for running finalizers or possibly a more subltle bug in managing
the lists of objects in different states of finalization. I will look
more carefully when I get a chance.
This is now fixed in R-devel and the R-patched (it was essentially a
missing PROTECT call).
luke
luke
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formal argument "envir" matched by multiple actual arguments
Thank you Luke! I know you made many people happy by fixing this one,
especially over at BioC.
Is this a candidate for the contest of the bug that survived the
longest without being caught?
I reported on its symptoms in April 2006, but I think I first observed
them in 2003-2004 (thinking for a long time that it was a problem with
my code).
/Henrik
On Fri, Jun 12, 2009 at 9:01 AM, wrote:
> On Tue, 2 Jun 2009, l...@stat.uiowa.edu wrote:
>
>> On Tue, 2 Jun 2009, Henrik Bengtsson wrote:
>>
>>> Nice case - I think you're onto something. /Henrik
>>>
>>> 2009/6/2 :
In fact reg.finalizer() looks like a dangerous feature.
If the finalizer itself triggers (implicitely or
explicitely) garbage collection, then bad things happen.
In the following example, garbage collection is triggered
explicitely (using R-2.9.0):
setClass("B", representation(bb="environment"))
newB <- function()
{
ans <- new("B", bb=new.env())
reg.finalizer(a...@bb,
function(e)
{
gc()
cat("cleaning", class(ans), "object...\n")
}
)
return(ans)
}
> for (i in 1:500) {cat(i, "\n"); b1 <- newB()}
1
2
3
4
5
6
...
13
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
14
...
169
170
171
Error: not a weak reference
Error: not a weak reference
[repeat the above line thousands of times]
...
Error: not a weak reference
Error: not a weak reference
cleaning B object...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
[repeat the above line thousands of times]
...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
172
...
246
247
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
*** caught segfault ***
address 0x41, cause 'memory not mapped'
Traceback:
1: gc()
2: function (e) { gc() cat("cleaning", class(ans),
"object...\n")}()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
Segmentation fault
So apparently, if the finalizer triggers garbage collection,
then we can end up with a corrupted session. Then anything can
happen, from the strange 'formal argument "envir" matched by
multiple actual arguments' error I reported in the previous post,
to a segfault. In the worse case, nothing apparently happens but
the output produced by the code is wrong.
Maybe garbage collection requests should be ignored during the
execution of the finalizer? (and more generally during garbbage
collection itself)
>>
>> Thanks for the report. The gc proper does not (or should not) do
>> anything that could cause allocation or trigger another gc. The gc
>> proper only identifies objects ready for finalization; running the
>> finalizers happens outside the gc proper where allocation and gc calls
>> should be safe. This looks like either a missing PROTECT call in the
>> code for running finalizers or possibly a more subltle bug in managing
>> the lists of objects in different states of finalization. I will look
>> more carefully when I get a chance.
>
> This is now fixed in R-devel and the R-patched (it was essentially a
> missing PROTECT call).
>
> luke
>
>>
>> luke
>>
>>
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> -
Re: [Rd] reference counting bug related to break and next in loops
> -Original Message-
> From: William Dunlap
> Sent: Wednesday, June 10, 2009 2:35 PM
> To: 'l...@stat.uiowa.edu'
> Cc: r-devel@r-project.org
> Subject: RE: [Rd] reference counting bug related to break and
> next in loops
>
> Thanks Luke.
>
> I used codetools::walkCode to look for functions that returned the
> value of a loop and found a surprising number in base R.
> However, it looks like non of these functions were written to return
> anything useful (the side effects were important), so the change
> to loop-returns-NULL should let such functions use less
> memory (and time) and make them correspond better to their
> documentation.
I also use walkCode to look for assignents whose right hand sides
were loops. The only *.R file in a directory containing a current R
build that had such a thing was
./library/base/R-ex/print.R
(from help(print)) and related files in ./tests. It had
rr <- for(i in 1:3) print(1:i)
rr
That last line used to print
[1] 1 2 3
and now prints
NULL
I didn't notice a corresponding *.Rout.save file so the test won't
notice the change in behavior.
I've attached the code I used. It is pretty crude.
functionReturnsLoopValue("file")
and functionAssignsLoopValue("file") parse "file" and then return a list
of functions
that return the value of a loop and a list of assignments involving the
value of a loop,
respectively. functionAssignsLoopValue looks for ordinary assignments
(x<-while(...))
and for default argument values (function(x=while(...)){}). It does not
yet look for
things passed as arguments in function calls, c(1, while(x>0)x<-x-1,
3). The last
might pick up some false positives involving functions that don't
evaluate their
arguments.
>
> E.g., fixup.libraries.URLs is not documented to return anything
> and it returns the value of for loop:
>
> $`src/library/utils/R/windows/linkhtml.R`[[2]]
> function(lib.loc = .libPaths())
> {
> for (lib in lib.loc) {
> if(lib == .Library) next
> pg <- sort(.packages(all.available = TRUE, lib.loc = lib))
> for(pkg in pg)
> try(fixup.package.URLs(file.path(lib,pkg)), silent = TRUE)
> }
> }
>
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
>
> > -Original Message-
> > From: l...@stat.uiowa.edu [mailto:l...@stat.uiowa.edu]
> > Sent: Wednesday, June 10, 2009 1:05 PM
> > To: William Dunlap
> > Cc: r-devel@r-project.org
> > Subject: Re: [Rd] reference counting bug related to break and
> > next in loops
> >
> > Thanks for the report.
> >
> > It turns out that a similar issue arises in while() loops without
> > break/next being involved because the test expression is evaluated
> > after the final body evaluation. After some discussion we
> decided it
> > was simplest both for implementation and documentation to have the
> > value of a loop expression always be NULL. This is now
> implemented in
> > R-devel.
> >
> > luke
> >
> > On Tue, 2 Jun 2009, William Dunlap wrote:
> >
> > > One of our R users here just showed me the following problem while
> > > investigating the return value of a while loop. I added some
> > > information
> > > on a similar bug in for loops. I think he was using 2.9.0
> > > but I see the same problem on today's development version
> of 2.10.0
> > > (svn 48703).
> > >
> > > Should the semantics of while and for loops be changed
> > slightly to avoid
> > > the memory
> > > buildup that fixing this to reflect the current docs would
> > entail? S+'s
> > > loops return nothing useful - that change was made long
> ago to avoid
> > > memory buildup resulting from semantics akin the R's
> > present semantics.
> > >
> > > Bill Dunlap
> > > TIBCO Software Inc - Spotfire Division
> > > wdunlap tibco.com
> > >
> > > Forwarded (and edited) message
> > >
> > below-
> > --
> > > --
> > >
> > > I think I have found another reference counting bug.
> > >
> > > If you type in the following in R you get what I think is
> the wrong
> > > result.
> > >
> > >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) {
> > break }; i =
> > > i + 1; y}; q
> > > [1] 42 42 42 42 42 42 42 42 9 10
> > >
> > > I had expected [1] 42 42 42 42 42 42 42 8 9 10 which is
> > what you get
> > > if you add 0 to y in the last statement in the while loop:
> > >
> > >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) {
> > break }; i =
> > > i + 1; y + 0}; q
> > > [1] 42 42 42 42 42 42 42 8 9 10
> > >
> > > Also,
> > >
> > >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break };
> > > i<-i+1 ; if (i<=8&&i>3)next ; cat("Completing iteration",
> > i, "\n"); y};
> > > q
> > > Completing iteration 2
> > > Completing iteration 3
> > > [1] 42 42 42 42 42 42 42 42 9 10
> > >
> > > but if the last statement in the while loop is y+0 instead
> > of y I get
> > > the
> > > expected result:
> > >
> > >> i = 1; y = 1:10; q =
Re: [Rd] formal argument "envir" matched by multiple actual arguments
Great news ! This bug was driving me mad.
I have some scripts that had _high_ probability of running into the
bug. I'll recompile and check it out over the weekend.
Kasper
On Jun 12, 2009, at 10:25 , Henrik Bengtsson wrote:
Thank you Luke! I know you made many people happy by fixing this one,
especially over at BioC.
Is this a candidate for the contest of the bug that survived the
longest without being caught?
I reported on its symptoms in April 2006, but I think I first observed
them in 2003-2004 (thinking for a long time that it was a problem with
my code).
/Henrik
On Fri, Jun 12, 2009 at 9:01 AM, wrote:
On Tue, 2 Jun 2009, l...@stat.uiowa.edu wrote:
On Tue, 2 Jun 2009, Henrik Bengtsson wrote:
Nice case - I think you're onto something. /Henrik
2009/6/2 :
In fact reg.finalizer() looks like a dangerous feature.
If the finalizer itself triggers (implicitely or
explicitely) garbage collection, then bad things happen.
In the following example, garbage collection is triggered
explicitely (using R-2.9.0):
setClass("B", representation(bb="environment"))
newB <- function()
{
ans <- new("B", bb=new.env())
reg.finalizer(a...@bb,
function(e)
{
gc()
cat("cleaning", class(ans), "object...\n")
}
)
return(ans)
}
> for (i in 1:500) {cat(i, "\n"); b1 <- newB()}
1
2
3
4
5
6
...
13
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
14
...
169
170
171
Error: not a weak reference
Error: not a weak reference
[repeat the above line thousands of times]
...
Error: not a weak reference
Error: not a weak reference
cleaning B object...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
[repeat the above line thousands of times]
...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
172
...
246
247
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
*** caught segfault ***
address 0x41, cause 'memory not mapped'
Traceback:
1: gc()
2: function (e) {gc()cat("cleaning", class(ans),
"object...\n")}()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
Segmentation fault
So apparently, if the finalizer triggers garbage collection,
then we can end up with a corrupted session. Then anything can
happen, from the strange 'formal argument "envir" matched by
multiple actual arguments' error I reported in the previous post,
to a segfault. In the worse case, nothing apparently happens but
the output produced by the code is wrong.
Maybe garbage collection requests should be ignored during the
execution of the finalizer? (and more generally during garbbage
collection itself)
Thanks for the report. The gc proper does not (or should not) do
anything that could cause allocation or trigger another gc. The gc
proper only identifies objects ready for finalization; running the
finalizers happens outside the gc proper where allocation and gc
calls
should be safe. This looks like either a missing PROTECT call in
the
code for running finalizers or possibly a more subltle bug in
managing
the lists of objects in different states of finalization. I will
look
more carefully when I get a chance.
This is now fixed in R-devel and the R-patched (it was essentially a
missing PROTECT call).
luke
luke
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
___
[Rd] Rprof loses all system() time
Rprof seems to ignore all time spent inside system() calls. E.g.,
this simple example actually takes about 10 seconds, but Rprof thinks
the total time is only 0.12 seconds:
> Rprof("sleep-system.out") ; system.time(system(command="sleep 10")) ;
> Rprof(NULL)
user system elapsed
0.000 0.004 10.015
> summaryRprof("sleep-system.out")$by.total
total.time total.pct self.time self.pct
"gc"0.12 100 0.12 100
"system.time" 0.12 100 0.000
>
I assume that what's going on here, is that anytime R blocks waiting
for data from a child process, the profiler stops running entirley,
and it then loses track of all that time spend blocking.
This Rprof behavior is frustrating, because I use a database access
layer which essentially works by having R call system() to run a shell
script. So, if I write a really slow query that takes 10 minutes to
run, as for as Rprof is concerned, those 10 minutes never happened,
the query consumed zero time. In complicated code, this makes it much
harder to figure out what parts are slow due to slow R code vs. slow
SQL queries.
Why does Rprof behave this way? Is there something I can do to
work-around or alleviate this? What do you think it would take to fix
Rprof to track the time spent waiting for system() to finish, and
where in the R source should I look to attempt that?
Thanks!
--
Andrew Piskorski
http://www.piskorski.com/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rprof loses all system() time
You could run proc.time() before and after each system call.
x <- proc.time()
# do something
y <- proc.time()
y - x
On Fri, Jun 12, 2009 at 5:31 PM, Andrew Piskorski wrote:
> Rprof seems to ignore all time spent inside system() calls. E.g.,
> this simple example actually takes about 10 seconds, but Rprof thinks
> the total time is only 0.12 seconds:
>
>> Rprof("sleep-system.out") ; system.time(system(command="sleep 10")) ;
>> Rprof(NULL)
> user system elapsed
> 0.000 0.004 10.015
>> summaryRprof("sleep-system.out")$by.total
> total.time total.pct self.time self.pct
> "gc" 0.12 100 0.12 100
> "system.time" 0.12 100 0.00 0
>>
>
> I assume that what's going on here, is that anytime R blocks waiting
> for data from a child process, the profiler stops running entirley,
> and it then loses track of all that time spend blocking.
>
> This Rprof behavior is frustrating, because I use a database access
> layer which essentially works by having R call system() to run a shell
> script. So, if I write a really slow query that takes 10 minutes to
> run, as for as Rprof is concerned, those 10 minutes never happened,
> the query consumed zero time. In complicated code, this makes it much
> harder to figure out what parts are slow due to slow R code vs. slow
> SQL queries.
>
> Why does Rprof behave this way? Is there something I can do to
> work-around or alleviate this? What do you think it would take to fix
> Rprof to track the time spent waiting for system() to finish, and
> where in the R source should I look to attempt that?
>
> Thanks!
>
> --
> Andrew Piskorski
> http://www.piskorski.com/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issues converting from JSON to R
When converting from JSON to R it seems logical that a JSON array would
correspond to an "unnamed" R list, while a JSON object would correspond to a
"named" R list. E.g.
JSON: [1, 3.1415927, "foo", false, null] => R: list(1, 3.1415927, "foo",
FALSE, NA);
and
JSON { "int": 1, "float": 3.1415927, "string": "foo", "logical": false,
"null": null } => R: list(int=1, float=3.1415927, string="foo",
logical=FALSE, null=NA)
But I see at least a couple of problems with this scheme. First, how would
one distinguish between the R versions of an empty JSON array (i.e. [ ]),
and an empty JSON object (i.e. { })?
Second, JSON allows the empty key in an object (e.g., this is a valid JSON
object: { "": 123 }), but as far as I can tell, R does not allow the empty
string as a name in a named list:
> list(""=123)
Error: attempt to use zero-length variable name
Any suggestions for dealing with these edge cases would be much appreciated!
TIA!
kynn
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issues converting from JSON to R
On Jun 12, 2009, at 6:34 PM, Kynn Jones wrote:
When converting from JSON to R it seems logical that a JSON array
would
correspond to an "unnamed" R list, while a JSON object would
correspond to a
"named" R list. E.g.
JSON: [1, 3.1415927, "foo", false, null] => R: list(1, 3.1415927,
"foo",
FALSE, NA);
note that NULL and NA are entirely different concepts - I don't think
mapping NULL to NA is a good idea ... why don't you just use NULL?
and
JSON { "int": 1, "float": 3.1415927, "string": "foo", "logical":
false,
"null": null } => R: list(int=1, float=3.1415927, string="foo",
logical=FALSE, null=NA)
But I see at least a couple of problems with this scheme. First,
how would
one distinguish between the R versions of an empty JSON array (i.e.
[ ]),
and an empty JSON object (i.e. { })?
Just add an attribute in that special case for one or the other. Or
even better in general you can make JSON dictionaries (or arrays as
well) a specific class (each) -- that would also help with future
dispatch when processing such objects. Also note that specific arrays
(scalar ones) are actually better mapped to vectors ...
Second, JSON allows the empty key in an object (e.g., this is a
valid JSON
object: { "": 123 }), but as far as I can tell, R does not allow the
empty
string as a name in a named list:
That's not true, try
l=list(123)
names(l)=""
list(""=123)
Error: attempt to use zero-length variable name
That has nothing to do with lists per se - the problem is the empty
argument name in the call to the function `list`. However, you'll be
creating the list programmatically so you won't run into that.
Cheers,
Simon
Any suggestions for dealing with these edge cases would be much
appreciated!
TIA!
kynn
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .doTrace problem with eval.parent(substitute(expr)) vs. lazy evaluation of expr
Here are a couple of problems with the use of
eval.parent(substitute(expr))
instead of just lazily evaluating expr in the .doTrace function used by
trace.
(a) In S+ I sometimes use trace() to see how long a function takes
to run with a tracer expression the saves the start time and calls
on.exit to report the difference between the start and end times
when the trace function ends. E.g.,
> trace(unix, Quote({START<-proc.time();on.exit(cat(command, "took",
proc.time()-START, "\n"))}))
> unix("sleep 4") # like R's system()
On entry: sleep 4 took 0 0 4.020001 0 0.01
character(0)
This trick fails in R (2.10.0 svn 48672):
> trace(system, Quote({START<-proc.time();on.exit(cat(command,
"took", proc.time()-START, "\n"))}))
Tracing function "system" in package "base"
[1] "system"
> system("sleep 4")
Tracing system("sleep 4") on entry
sleep 4 took 0 0 0 0 0
[4 second pause before the next prompt]
If I change .doTrace by changing its
exprObj <- substitute(expr)
eval.parent(exprObj)
to just
expr # evaluate in caller's environment by lazy evaluation
then the on.exit works as I wished it to. I think the on.exit clause
is being executed at the end of eval.parent() instead of at the end of
the caller of .doTrace (put print(sys.calls()) into the on.exit to see
the evidence).
(b) Another thing I'm used to doing with trace() in S+ is to selectively
expand some of the arguments of the traced function (so I can see
its value instead of just its name), as in
> trace(match,
Quote({CALL<-match.call();CALL$x<-paste(class(x),"(",length(x),")",sep="
");print(CALL)}))
> for(x in list(factor(letters), 1:2, "c"))match(x,c("c","d","e"))
On entry: match(x = "character(26)", table = exclude)
On entry: match(x = "character(26)", table = levels)
On entry: match(x = "factor(26)", table = c("c", "d", "e"))
On entry: match(x = "character(26)", table = table, nomatch =
nomatch, incomparables =
incomparables)
On entry: match(x = "integer(2)", table = c("c", "d", "e"))
On entry: match(x = "character(1)", table = c("c", "d", "e"))
This fails in R
> for(x in list(factor(letters), 1:2, "c"))match(x,c("c","d","e"))
Tracing match(x, table, nomatch = 0L) on entry
Error in match.call() :
unable to find a closure from within which 'match.call' was called
until I make that change to .doTrace
> for(x in list(factor(letters), 1:2, "c"))match(x,c("c","d","e"))
Tracing match(x, table, nomatch = 0L) on entry
match(x = "character(1)", table = table, nomatch = 0L)
Tracing match(levels, exclude) on entry
match(x = "character(26)", table = exclude)
Tracing match(x, levels) on entry
match(x = "character(26)", table = levels)
Tracing match(x, c("c", "d", "e")) on entry
match(x = "factor(26)", table = c("c", "d", "e"))
Tracing match(x, c("c", "d", "e")) on entry
match(x = "integer(2)", table = c("c", "d", "e"))
Tracing match(x, c("c", "d", "e")) on entry
match(x = "character(1)", table = c("c", "d", "e"))
Would there be any harm in making this change to .doTrace?
I can avoid the on.exit problem by using both the tracer and exit
arguments to
trace:
> trace(system, Quote(START<-proc.time()), exit=Quote(cat(command,
"took", proc.time()-START, "\n")))
Tracing function "system" in package "base"
[1] "system"
> system("sleep 4")
Tracing system("sleep 4") on entry
Tracing system("sleep 4") on exit
sleep 4 took 0.001 0.002 4.018 0.002 0.002
but I do miss the ability of the tracer to use match.call().
Are there other properties lost by using eval.parent(substitute(expr))
instead lazily evaluating expr? Should eval.parent(substitute(expr))
try to mimic more closely the lazy evaluation of expr?
The patch I used for testing was
Index: src/library/base/R/methodsSupport.R
===
--- src/library/base/R/methodsSupport.R (revision 48762)
+++ src/library/base/R/methodsSupport.R (working copy)
@@ -87,8 +87,7 @@
call <- paste(call[[1L]], "")
cat("Tracing", call, msg, "\n")
}
-exprObj <- substitute(expr)
-eval.parent(exprObj)
+expr # lazily evaluate expr
}
NULL
}
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formal argument "envir" matched by multiple actual arguments
That's great news Luke! Thanks for finding and fixing that one!
I will do some testing and update the BioC build system with
the latest R.
H.
l...@stat.uiowa.edu wrote:
On Tue, 2 Jun 2009, l...@stat.uiowa.edu wrote:
On Tue, 2 Jun 2009, Henrik Bengtsson wrote:
Nice case - I think you're onto something. /Henrik
2009/6/2 :
In fact reg.finalizer() looks like a dangerous feature.
If the finalizer itself triggers (implicitely or
explicitely) garbage collection, then bad things happen.
In the following example, garbage collection is triggered
explicitely (using R-2.9.0):
setClass("B", representation(bb="environment"))
newB <- function()
{
ans <- new("B", bb=new.env())
reg.finalizer(a...@bb,
function(e)
{
gc()
cat("cleaning", class(ans), "object...\n")
}
)
return(ans)
}
> for (i in 1:500) {cat(i, "\n"); b1 <- newB()}
1
2
3
4
5
6
...
13
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
14
...
169
170
171
Error: not a weak reference
Error: not a weak reference
[repeat the above line thousands of times]
...
Error: not a weak reference
Error: not a weak reference
cleaning B object...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
[repeat the above line thousands of times]
...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a
'integer'
172
...
246
247
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
*** caught segfault ***
address 0x41, cause 'memory not mapped'
Traceback:
1: gc()
2: function (e) {gc()cat("cleaning", class(ans),
"object...\n")}()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
Segmentation fault
So apparently, if the finalizer triggers garbage collection,
then we can end up with a corrupted session. Then anything can
happen, from the strange 'formal argument "envir" matched by
multiple actual arguments' error I reported in the previous post,
to a segfault. In the worse case, nothing apparently happens but
the output produced by the code is wrong.
Maybe garbage collection requests should be ignored during the
execution of the finalizer? (and more generally during garbbage
collection itself)
Thanks for the report. The gc proper does not (or should not) do
anything that could cause allocation or trigger another gc. The gc
proper only identifies objects ready for finalization; running the
finalizers happens outside the gc proper where allocation and gc calls
should be safe. This looks like either a missing PROTECT call in the
code for running finalizers or possibly a more subltle bug in managing
the lists of objects in different states of finalization. I will look
more carefully when I get a chance.
This is now fixed in R-devel and the R-patched (it was essentially a
missing PROTECT call).
luke
luke
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
