[Rd] Weird erratic error and illogical error message, could someone explain this?

[Philippe Grosjean]

Martin,

This looks like a possible explanation. After double-check, it occurs 
with R 2.10.1 and 2.11.0 (not 2.11.1, as I reported in my original 
email). I'll upgrade R and test again. I'll report the results on 
Monday, since my code has to run over the week-end.
Thanks,

PhG

On 03/09/10 14:53, Martin Morgan wrote:
> On 09/03/2010 04:42 AM, Duncan Murdoch wrote:
>> Philippe Grosjean wrote:
>>> Hello,
>>>
>>> It's several days I try to track this bug, and even cannot cook a
>>> reproducible example. Yet, it occurs consistently in a long-running
>>> task after a variable period of time. Here is an example:
>>>
>>
>> I would look closely at the other software that is running in your
>> long example.  Does it include C (or other external) code?  Look
>> closely at that, it might be writing outside it's own allocated
>> memory.  Also check for correct protection of intermediate results, if
>> you're producing SEXPs in the external code.  (Running under gctorture
>> might flush out the bug more quickly if the latter is the problem.)
>>
>> If you're only running R code, then this looks like a bug in R, but it
>> might still be worth trying gctorture to make it reproducible.  We
>> won't be able to fix it if we can't reproduce it.
>>
>> Duncan Murdoch
>>> ... my long-running code [as I said, cannot give something simple
>>> that produces this bug in a reproducible manner]
>>>
>>> Error in match(x, table, nomatch = 0L) :
>>>       formal argument "nomatch" matched by multiple actual arguments
>>>   >  traceback()
>>> 6: match(x, table, nomatch = 0L)
>>> 5: "factor" %in% attrib[["class", exact = TRUE]]
>>> 4: structure(.Internal(Sys.time()), class = c("POSIXt", "POSIXct"))
>>> 3: Sys.time()
>>> 2: chemTrigger() at chemostat_1.0-1.R#1132
>>> 1: chemRun()
>
> I think this is a bug in R that has been fixed in the subversion commit
> below, and so should be fixed in R-2.11.1.
> What is your sessionInfo(), and does your error occur in the devel
> version of R?
>
> Martin
>
> r51232 | falcon | 2010-03-09 13:59:48 -0800 (Tue, 09 Mar 2010) | 14 lines
> Changed paths:
>     M /trunk/src/main/match.c
>
> Fix bug in matchArgs triggered by gc and finalizers
>
> matchArgs was modifying the general purpose bits of SEXPs making up the
> 'formals' argument to keep track of ARGUSED.  When gc is triggered
> inside matchArgs, finalizer code can end up calling matchArgs on the
> same function (hence same formals) resulting in corruption of gp bits.
>
> This patch uses an int array allocated on the stack to keep track of
> ARGUSED and avoids modifying the SEXPs in formals.  In place modification
> of SEXPs in supplied still occurs via ARGUSED/SET_ARGUSED, but should be
> safe as long as no new allocating function calls are added to matchArgs.
>
> A reproducible report of this bug was reported here:
> https://stat.ethz.ch/pipermail/bioc-sig-sequencing/2010-March/000997.html
>
>
>>>
>>> So, the culprid is a call inside `%in%` (from within structure() in
>>> Sys.time()). But I can run millions times `%in%`, or structure(), or
>>> Sys.time() on my machine without producing this bug. Arguments at 5:
>>> are simple character strings. They don't hurt!
>>>
>>> Also, I am lost because the message is totally illogical in the
>>> context where it appears: I can understand this message here:
>>>
>>>   >  match(1, 2, nomatch = 0L, nomatch = NA)
>>> Error in match(1, 2, nomatch = 0L, nomatch = NA) :
>>>     formal argument "nomatch" matched by multiple actual arguments
>>>
>>> or here:
>>>
>>>   >  test<- function (...) match(1, ..., nomatch = 0L)
>>>   >  test(2, nomatch = NA)
>>> Error in match(1, ..., nomatch = 0L) :
>>>     formal argument "nomatch" matched by multiple actual arguments
>>>
>>> but in the call "match(x, table, nomatch = 0L)" where x is the
>>> character string "factor" and table is another character string
>>> ("numeric") extracted from a list, I don't understand why it produces
>>> this error message. '.Internal(Sys.time())' uses do_systime c code
>>> that returns a one-element double... not something that can hurt here?!
>>>
>>> Can someone explain me, or give me an example where an argument is
>>> NOT duplicated in the call (well, as I understand it here) and where
>>> one gets such an error message? And why?
>>>
>>> Many thanks, I am desperate :-(
>>>
>>> I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on
>>> Windows XP SP3 (but it does not matter, since I cannot cook a
>>> reproducible example).
>>>
>>> Philippe
>>>
>>> P.S.: seems related to this:
>>> http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html
>>>
>>
>> ______________________________________________
>> 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
>
>