Hi,
> gctorture(TRUE)
> setGeneric("foo", function(x, y) standardGeneric("foo"))
[1] "foo"
> setMethod("foo", c("ANY", "ANY"),
+ function(x, y) cat("calling foo,ANY,ANY method\n")
+ )
Error: protect(): protection stack overflow
Sorry this is something I already reported one week ago here
https://stat.ethz.ch/pipermail/r-devel/2009-July/053973.html
but I just had a 2nd look at it and realized that the problem
can in fact be reproduced out of the .onLoad() hook. So I'm
reporting it again with a different subject.
See my sessionInfo() below. Thanks!
H.
sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-26 r48837)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Hi,
> x <- c(a=10, b=20)
> length(x) <- 1
> x
a
10
But with gctorture turned on, I get:
> gctorture(TRUE)
> x <- c(a=10, b=20)
> length(x) <- 1
> x
a
"a" <---- ???
> x <- c(a=10, b=20)
> length(x) <- 3
*** caught segfault ***
address (nil), cause 'unknown'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
This seems to have been around for a while (I get this with R 2.10,
2.9 and 2.8). Note that I don't get this with an unnamed vector.
This problem affects the methods package. I found it while
troubleshooting the "Protection stack overflow" I reported earlier
(see https://stat.ethz.ch/pipermail/r-devel/2009-July/054030.html)
but I can't tell yet whether the 2 issues are related or not.
It would be nice to see some reaction from the R developers
about these issues. Thanks in advance!
H.
+ function(x, y) cat("calling foo,ANY,ANY method\n")
+ )
Error: protect(): protection stack overflow
Sorry this is something I already reported one week ago here
https://stat.ethz.ch/pipermail/r-devel/2009-July/053973.html
but I just had a 2nd look at it and realized that the problem
can in fact be reproduced out of the .onLoad() hook. So I'm
reporting it again with a different subject.
See my sessionInfo() below. Thanks!
H.
sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-26 r48837)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Herv? Pag?s
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages at fhcrc.org
Phone: (206) 667-5791
Fax: (206) 667-1319
"HP" == Herv? Pag?s <hpages at fhcrc.org>
on Wed, 15 Jul 2009 17:08:20 -0700 writes:
HP> Hi,
>> x <- c(a=10, b=20)
>> length(x) <- 1
>> x
HP> a
HP> 10
HP> But with gctorture turned on, I get:
>> gctorture(TRUE)
>> x <- c(a=10, b=20)
>> length(x) <- 1
>> x
HP> a
HP> "a" <---- ???
>> x <- c(a=10, b=20)
>> length(x) <- 3
HP> *** caught segfault ***
HP> address (nil), cause 'unknown'
HP> Possible actions:
HP> 1: abort (with core dump, if enabled)
HP> 2: normal R exit
HP> 3: exit R without saving workspace
HP> 4: exit R saving workspace
HP> This seems to have been around for a while (I get this with R 2.10,
HP> 2.9 and 2.8). Note that I don't get this with an unnamed vector.
HP> This problem affects the methods package. I found it while
HP> troubleshooting the "Protection stack overflow" I reported earlier
HP> (see https://stat.ethz.ch/pipermail/r-devel/2009-July/054030.html)
HP> but I can't tell yet whether the 2 issues are related or not.
HP> It would be nice to see some reaction from the R developers
HP> about these issues. Thanks in advance!
Salut Herv?,
so here comes "some reaction" ..
{You know we had "useR! 2009" in Rennes, a big success I think,
and then a very nice "DSC 2009" in Copenhagen, so many R
developers were either attending or then were vacationing / too
busy to attend ==> all reasons for not getting quick replies}
Indeed, you have uncovered quite a nasty bug, and R core will
definitely address it sooner or later.
However, I'm not the one doing that for the time being,
as garbage collection and the protection stack is not my home
ground.
BTW: My subjective probability is pretty high that indeed this
bug is related to the one you encountered with
setGeneric() & setMethod() calls, as I also get a
"Protection stack overflow" using a variation of the
example above.
BTW, running under gdb :
gctorture(TRUE)
x <- c(a=10, b=20) ; length(x) <- 1
dput(x)
Program received signal SIGSEGV, Segmentation fault.
0x000000366f823184 in __gconv_transform_utf8_internal () from /lib64/libc.so.6
(gdb) bt
#0 0x000000366f823184 in __gconv_transform_utf8_internal ()
from /lib64/libc.so.6
#1 0x000000366f88988b in mbrtowc () from /lib64/libc.so.6
#2 0x000000000046e4b1 in Rstrwid (str=0xad76e0 "a", slen=1,
ienc=<value optimized out>, quote=34)
at ../../../R/src/main/printutils.c:304
#3 0x000000000057ed93 in Rf_formatString (x=<value optimized out>, n=1,
fieldwidth=0x7fffff3ff1ac, quote=11368166)
at ../../../R/src/main/format.c:60
#4 0x000000000046f87f in Rf_EncodeElement (x=<value optimized out>,
indx=<value optimized out>, quote=34, dec=46 '.')
at ../../../R/src/main/printutils.c:643
#5 0x0000000000534359 in vector2buff (d=<value optimized out>,
vector=<value optimized out>) at ../../../R/src/main/deparse.c:1326
#6 deparse2buff (d=<value optimized out>, vector=<value optimized out>)
at ../../../R/src/main/deparse.c:1129
#7 0x0000000000537249 in attr2 (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:571
#8 0x000000000053417d in deparse2buff (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:746
#9 0x0000000000537249 in attr2 (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:571
#10 0x000000000053417d in deparse2buff (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:746
#11 0x0000000000537249 in attr2 (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:571
#12 0x000000000053417d in deparse2buff (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:746
..............
#23613 0x0000000000537249 in attr2 (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:571
#23614 0x000000000053417d in deparse2buff (s=0x1913148, d=0x7fffffffb8b0)
at ../../../R/src/main/deparse.c:746
...............
which very very strongly looks like an infinite loop
( that is not properly caught in the usual way ).
---
Martin
"MM" == Martin Maechler <maechler at stat.math.ethz.ch>
on Thu, 16 Jul 2009 17:56:07 +0200 writes:
...............
HP> This seems to have been around for a while (I get this with R 2.10,
HP> 2.9 and 2.8). Note that I don't get this with an unnamed vector.
HP> This problem affects the methods package. I found it while
HP> troubleshooting the "Protection stack overflow" I reported earlier
HP> (see https://stat.ethz.ch/pipermail/r-devel/2009-July/054030.html)
HP> but I can't tell yet whether the 2 issues are related or not.
HP> It would be nice to see some reaction from the R developers
HP> about these issues. Thanks in advance!
MM> Salut Herv?,
MM> so here comes "some reaction" ..
MM> {You know we had "useR! 2009" in Rennes, a big success I think,
MM> and then a very nice "DSC 2009" in Copenhagen, so many R
MM> developers were either attending or then were vacationing / too
MM> busy to attend ==> all reasons for not getting quick replies}
MM> Indeed, you have uncovered quite a nasty bug, and R core will
MM> definitely address it sooner or later.
MM> However, I'm not the one doing that for the time being,
MM> as garbage collection and the protection stack is not my home
MM> ground.
hmm, ... actually I was able to fix this bug in spite of all I
said...
but when I tried to commit my fix, I saw that Duncan Murdoch
has been faster ...
Regards,
Martin