From luke at stat.uiowa.edu  Fri Jun 12 18:01:42 2009
From: luke at stat.uiowa.edu (luke at stat.uiowa.edu)
Date: Fri, 12 Jun 2009 11:01:42 -0500 (CDT)
Subject: [Rd] formal argument "envir" matched by multiple actual
 arguments
In-Reply-To: <alpine.LFD.2.00.0906021031000.7161@nokomis.stat.uiowa.edu>
References: <4A24839C.50403@fhcrc.org>
	<20090602010540.k6d93dfdycc884wg@webmail.fhcrc.org>
	<59d7961d0906020125w5b399755j594a018ca608318c@mail.gmail.com>
	<alpine.LFD.2.00.0906021031000.7161@nokomis.stat.uiowa.edu>
Message-ID: <alpine.LFD.2.00.0906121100350.7161@nokomis.stat.uiowa.edu>

On Tue, 2 Jun 2009, luke at stat.uiowa.edu wrote:

> On Tue, 2 Jun 2009, Henrik Bengtsson wrote:
>
>> Nice case - I think you're onto something. /Henrik
>> 
>> 2009/6/2  <hpages at fhcrc.org>:
>>> 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(ans at 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")}(<environment>)
>>> 
>>> ? 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>> ______________________________________________
>> R-devel at 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 and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu


[Rd] formal argument "envir" matched by multiple actual arguments
luke at stat.uiowa.edu