[Rd] formal argument "envir" matched by multiple actual arguments

[luke at 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