Message-ID: <59d7961d0906121025hce4f27dmf9fdfb6e8bc6897c@mail.gmail.com>
Date: 2009-06-12T17:25:30Z
From: Henrik Bengtsson
Subject: formal argument "envir" matched by multiple actual arguments
In-Reply-To: <alpine.LFD.2.00.0906121100350.7161@nokomis.stat.uiowa.edu>
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, <luke at stat.uiowa.edu> wrote:
> 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
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>