From hb at stat.berkeley.edu  Sun Sep  5 06:17:42 2010
From: hb at stat.berkeley.edu (Henrik Bengtsson)
Date: Sat, 4 Sep 2010 21:17:42 -0700
Subject: [Rd] Weird erratic error and illogical error message,
 could someone explain this?
In-Reply-To: <4C80FFBC.90200@sciviews.org>
References: <4C80B1FA.9060403@sciviews.org> <4C80DF09.9030805@gmail.com>
	<4C80EFCE.3070400@fhcrc.org> <4C80FFBC.90200@sciviews.org>
Message-ID: <AANLkTin35A3XPSpBNRuZXPKgZUW-kVw+UocfVw9CjaZZ@mail.gmail.com>

This looks like a good old friend or maybe its cousin... it's been
discovered, confusing us and also debugged several times before:

http://tolstoy.newcastle.edu.au/R/devel/06/04/4861.html
http://tolstoy.newcastle.edu.au/R/e6/devel/09/06/2081.html

/Henrik

On Fri, Sep 3, 2010 at 7:01 AM, Philippe Grosjean
<phgrosjean at sciviews.org> wrote:
> 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
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



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