[Rd] more on bug 7924

[Kevin B. Hendricks]

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