Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
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() 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
Thank you, Duncan for your answer. Indeed, I have also tcltk loaded and running, and the memory allocation problem may come from there. I'll investigate using gctorture(). For sure, I know that I need a reproducible example for further investigations. Best, Philippe ..<°}))>< ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons University, Belgium ( ( ( ( ( .. On 03/09/10 13:42, 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() 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
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 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.
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
Just to give feedback after running my program during the week-end: the bugs has disappeared and everything runs fine now. The only change I did was to upgrade to latest patched version of R 1.11.1. It is probable that my problem was fixed by: 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 Thanks for the help. Best, Philippe On 05/09/10 06:17, Henrik Bengtsson wrote: 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 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