[Rd] more on bug 7924
Hin-Tak Leung
hin-tak.leung at cimr.cam.ac.uk
Mon Jun 5 12:10:45 CEST 2006
I see you have found the sexptype listing in Rinternals.h . I believe
it was in one of R's FAQ's about R's garbage collector - it doesn't do
proper reference-counted garbage collection as you suggested, but does
a sort of poor man's garbage collection, by classifying entities in
*only* 3 catergories - not-in-use, in-used-by-one, and in-used
by-more-than-one.
Kevin B. Hendricks wrote:
> Hi,
>
> Okay I threw together a quick dump_object routine and found something
> that I don't think is correct when call2 is created.
>
> > call2 <- Quote(f(arg[[1]]))[c(1,2,2,2)]
> > get("call2")
>
> I use the do_get break to find the SEXP value I want
>
> Breakpoint 1, do_get (call=0xc2d530, op=0x52bd30, args=0x9e83a8,
> rho=Variable "rho" is not available.
> ) at ../../../r-devel/r-devel/R/src/main/envir.c:1668
> 1668 if (PRIMVAL(op)) { /* have get(.) */
>
>
> (gdb) print *rval
> $2 = {sxpinfo = {type = 6, obj = 0, named = 1, gp = 0, mark = 0,
> debug = 0, trace = 0, fin = 0, gcgen = 0, gccls = 0}, attrib =
> 0x508818, gengc_next_node = 0x9e7d50,
> gengc_prev_node = 0x9e7ce0, u = {primsxp = {offset = 10663048},
> symsxp = {pname = 0xa2b488, value = 0x9e7ce0, internal = 0x508818},
> listsxp = {carval = 0xa2b488,
> cdrval = 0x9e7ce0, tagval = 0x508818}, envsxp = {frame =
> 0xa2b488, enclos = 0x9e7ce0, hashtab = 0x508818}, closxp = {formals =
> 0xa2b488, body = 0x9e7ce0,
> env = 0x508818}, promsxp = {value = 0xa2b488, expr = 0x9e7ce0,
> env = 0x508818}}}
>
>
> Now I invoke my own dump routine which keeps track of recursion level
> and will dump the named and other things inside the newly created
> object, the format of the output is
>
> recursion level: SEXP X TYPEOF(X) and then some object specific values
>
>
> (gdb) call dump_object(rval, 0)
>
>
> 0: 0x9e7d18 LANGSXP Object with length 1, named 1
> f(arg[[1]], arg[[1]], arg[[1]])
> 1: 0xa2b488 SYMSXP name at 0xa29408, value at 0x5087e0, named 0
> f
> 1: 0x9e9880 LANGSXP Object with length 1, named 0
> arg[[1]]
> 2: 0x508738 SYMSXP name at 0x51c788, value at 0x527690, named 0
> `[[`
> 2: 0xc37cc8 SYMSXP name at 0xc376e8, value at 0x5087e0, named 0
> arg
> 2: 0xf94cb8 REALSXP Object, length 1, starting at 0xf94ce0, named 0
> 1
> 1: 0x9e9880 LANGSXP Object with length 1, named 0
> arg[[1]]
> 2: 0x508738 SYMSXP name at 0x51c788, value at 0x527690, named 0
> `[[`
> 2: 0xc37cc8 SYMSXP name at 0xc376e8, value at 0x5087e0, named 0
> arg
> 2: 0xf94cb8 REALSXP Object, length 1, starting at 0xf94ce0, named 0
> 1
> 1: 0x9e9880 LANGSXP Object with length 1, named 0
> arg[[1]]
> 2: 0x508738 SYMSXP name at 0x51c788, value at 0x527690, named 0
> `[[`
> 2: 0xc37cc8 SYMSXP name at 0xc376e8, value at 0x5087e0, named 0
> arg
> 2: 0xf94cb8 REALSXP Object, length 1, starting at 0xf94ce0, named 0
> 1
>
>
>
> Notice how each LANGSXP subobject reuses the exact same objects/
> addresses (notice the address are the same) 3 times (one for each
> entry) but the named value is always 0 for all of them (even though
> that address is being re-used (effectively "named") each time.
>
> 1: 0x9e9880 LANGSXP Object with length 1, named 0
> arg[[1]]
> 2: 0x508738 SYMSXP name at 0x51c788, value at 0x527690, named 0
> `[[`
> 2: 0xc37cc8 SYMSXP name at 0xc376e8, value at 0x5087e0, named 0
> arg
> 2: 0xf94cb8 REALSXP Object, length 1, starting at 0xf94ce0, named 0
> 1
>
>
> Shouldn't all 3 copies have named set to 1 and not zero since they
> are all pointing to the same pieces of memory? And shouldn't that
> force the top level LANGSXP object to have named of 2 in this case
> and not its current value of 1.
>
>
> How should any assignment to any of those 3 places in the LANGSXP
> list ever know they must be duplicated first when all of the named
> values are 0 even though they all point to the same block of memory?
>
> I truly do not understand how named is being used in this case. Why
> don't we simply refcount all allocated objects so we know what the
> true value of named must be? How else can we get that information?
>
> Hints welcome especially to reading material that explains more on
> this stuff.
>
> Thanks,
>
> Kevin
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list