[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