[Rd] formal argument "envir" matched by multiple actual arguments
Kasper Daniel Hansen
khansen at stat.berkeley.edu
Fri Jun 12 22:42:46 CEST 2009
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, <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
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list