Bug 14217 - Rubbish values written with zero-length vectors
Rubbish values written with zero-length vectors
Status: CLOSED FIXED
Product: R
Classification: Unclassified
Component: Low-level
old
ix86 (32-bit) Windows 32-bit
: P5 normal
Assigned To: Jitterbug compatibility account
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-19 18:42 UTC by Jitterbug compatibility account
Modified: 2014-02-16 11:42 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jitterbug compatibility account 2010-02-19 18:42:35 UTC
From: g.russell@eos-solutions.com
Full_Name: George Russell
Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
OS: Windows
Submission from: (NULL) (217.111.3.131)


R trace:
-- cut here --
> v <- integer(0)
> v[[1]] <- v
> v
[1] 20522144
> v <- numeric(0)
> v[[1]] <- v
> v
[1] 4.254131e-314
> sessionInfo()
R version 2.10.0 (2009-10-26) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252   
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                   
[5] LC_TIME=German_Germany.1252    

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     
-- cut here --
Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
don't understand where the strange values left in v come from.

The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
vanilla in Windows CMD mode I get different values in v, but ones which are to
me equally strange.

Many thanks for your help!

George Russell

Comment 1 Jitterbug compatibility account 2010-02-20 21:37:12 UTC
From: Henrik Bengtsson <hb@stat.berkeley.edu>
Confirmed behavior on R version 2.10.1 Patched (2010-01-12 r50990) and
R version 2.11.0 Under development (unstable) (2010-02-14 r51138)
[Windows Vista]:

INTEGERS:
> v <- integer(5)
> v
[1] 0 0 0 0 0
> v[[2]] <- integer(0)
> v
[1]       0 2892960       0       0       0
> v[[4]] <- 1L[c()]
> v
[1]       0 2892960       0 2892960       0
> str(v)
 int [1:5] 0 2892960 0 2892960 0

DOUBLES:
> u <- integer(5)
> u
[1] 0 0 0 0 0
> u[[2]] <- integer(0)
> u
[1]       0 2892960       0       0       0
> u[[4]] <- 1L[c()]
> u
[1]       0 2892960       0 2892960       0
> str(u)
 str [1:5] 0 2892960 0 2892960 0

> u[[5]] <- double(0)
> u
[1]  0.000000e+00  3.487453e+07  0.000000e+00  3.487453e+07 4.261222e-314
> str(u)
 num [1:5] 0.00 3.49e+07 0.00 3.49e+07 4.26e-314

The actual "rubbish" values are the same within each R session, but
differ between R sessions.

Certain looks like stray memory cells are assigned.

Wanted behavior should probably be:

> u[[5]] <- double(0)
Error in u[[5]] <- double(0) : replacement has length zero

cf. u[5] <- double(0) and

> u[[5]] <- double(5)
Error in u[[5]] <- double(5) :
  more elements supplied than there are to replace

/Henrik

On Fri, Feb 19, 2010 at 1:45 PM,  <g.russell@eos-solutions.com> wrote:
> Full_Name: George Russell
> Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
> OS: Windows
> Submission from: (NULL) (217.111.3.131)
>
>
> R trace:
> -- cut here --
>> v <- integer(0)
>> v[[1]] <- v
>> v
> [1] 20522144
>> v <- numeric(0)
>> v[[1]] <- v
>> v
> [1] 4.254131e-314
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
> [5] LC_TIME=German_Germany.1252
>
> attached base packages:
> [1] stats     graphics  grDevices datasets  utils     methods   base
> -- cut here --
> Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
> don't understand where the strange values left in v come from.
>
> The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
> vanilla in Windows CMD mode I get different values in v, but ones which are to
> me equally strange.
>
> Many thanks for your help!
>
> George Russell
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Comment 2 Jitterbug compatibility account 2010-02-20 21:50:24 UTC
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
g.russell@eos-solutions.com wrote:
> Full_Name: George Russell
> Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
> OS: Windows
> Submission from: (NULL) (217.111.3.131)
> 
> 
> R trace:
> -- cut here --
>> v <- integer(0)
>> v[[1]] <- v
>> v
> [1] 20522144
>> v <- numeric(0)
>> v[[1]] <- v
>> v
> [1] 4.254131e-314
>> sessionInfo()
> R version 2.10.0 (2009-10-26) 
> i386-pc-mingw32 
> 
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252   
> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                   
> [5] LC_TIME=German_Germany.1252    
> 
> attached base packages:
> [1] stats     graphics  grDevices datasets  utils     methods   base     
> -- cut here --
> Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
> don't understand where the strange values left in v come from.

You don't want to understand, believe me! ;-)

It's a bug, probably not the very worst kind, but accessing memory that 
isn't yours is potentially harmful (but writing to it is considerably 
worse).

Looks like the issue only concerns the right hand side; nothing to do 
with the auto-expansion of v. I also get

 > v <- integer(0)
 > u <- integer(1)
 > u[[2]] <-v
 > u
[1]         0 142000760
 > u[[1]] <-v
 > u
[1] 142000760 142000760
 > a <- 1
 > a[[1]] <-v
 > a
[1] 142000760


> 
> The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
> vanilla in Windows CMD mode I get different values in v, but ones which are to
> me equally strange.
> 
> Many thanks for your help!
> 
> George Russell
> 
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
  (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)              FAX: (+45) 35327907

Comment 3 Jitterbug compatibility account 2010-02-21 04:21:21 UTC
From: Seth Falcon <seth@userprimary.net>
On 2/20/10 7:50 AM, Peter Dalgaard wrote:
> You don't want to understand, believe me! ;-)
> 
> It's a bug, probably not the very worst kind, but accessing memory that
> isn't yours is potentially harmful (but writing to it is considerably
> worse).
> 
> Looks like the issue only concerns the right hand side; nothing to do
> with the auto-expansion of v. I also get
> 
>> v <- integer(0)
>> u <- integer(1)
>> u[[2]] <-v
>> u
> [1]         0 142000760
>> u[[1]] <-v
>> u
> [1] 142000760 142000760
>> a <- 1
>> a[[1]] <-v
>> a
> [1] 142000760

I'm thinking this should be an error.  Similar to:

> v = 1
> v[[1]] = integer(3)
Error in v[[1]] = integer(3) :
  more elements supplied than there are to replace

But instead not enough elements supplied.  Perhaps:

> v[[1]] = integer()
Error in v[[1]] = integer() : [[ ]] replacement has zero length

The code in do_subassign2_dflt currently does not check that the
replacement has length > 0 for the nsubs == 1 case.  I think we want:


@@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
SEXP rho)
        if (nsubs == 0 || CAR(subs) == R_MissingArg)
            error(_("[[ ]] with missing subscript"));
        if (nsubs == 1) {
+            if (length(y) == 0)
+                error(_("[[ ]] replacement has zero length"));
            offset = OneIndex(x, thesub, length(x), 0, &newname,
recursed ? len-1 : -1, R_NilValue);
            if (isVectorList(x) && isNull(y)) {
                x = DeleteOneVectorListItem(x, offset);


+ seth

Comment 4 Jitterbug compatibility account 2010-02-21 14:36:22 UTC
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
seth@userprimary.net wrote:

Thanks, Seth. Martin Morgan sent a patch for a few lines above yours, 
which I didn't have a chance to review until now:

-   if (!isVectorList(x) && LENGTH(y) > 1)
-       error(_("more elements supplied than there are to replace"));
+   if (!isVectorList(x) && LENGTH(y) != 1)
+       if (LENGTH(y) == 0)
+           error(_("fewer elements supplied than there are to replace"));
+       else
+           error(_("more elements supplied than there are to replace"));

I _think_ that you are both right that there is no way for a zero-length 
RHS not to be an error. E.g.,

 > x[[0]] <- real(0)
Error in x[[0]] <- real(0) : attempt to select less than one element

The difference between Seth's solution and Martin's is whether to 
pre-check for nsubs==1, and I don't think we want that because of

 > x <- matrix(1:4,2,2)
 > x[[2,2]]
[1] 4
 > x[[2,2]] <- integer(0)
 > x
      [,1]      [,2]
[1,]    1         3
[2,]    2 142000760


> On 2/20/10 7:50 AM, Peter Dalgaard wrote:
>> You don't want to understand, believe me! ;-)
>>
>> It's a bug, probably not the very worst kind, but accessing memory that
>> isn't yours is potentially harmful (but writing to it is considerably
>> worse).
>>
>> Looks like the issue only concerns the right hand side; nothing to do
>> with the auto-expansion of v. I also get
>>
>>> v <- integer(0)
>>> u <- integer(1)
>>> u[[2]] <-v
>>> u
>> [1]         0 142000760
>>> u[[1]] <-v
>>> u
>> [1] 142000760 142000760
>>> a <- 1
>>> a[[1]] <-v
>>> a
>> [1] 142000760
> 
> I'm thinking this should be an error.  Similar to:
> 
>> v = 1
>> v[[1]] = integer(3)
> Error in v[[1]] = integer(3) :
>   more elements supplied than there are to replace
> 
> But instead not enough elements supplied.  Perhaps:
> 
>> v[[1]] = integer()
> Error in v[[1]] = integer() : [[ ]] replacement has zero length
> 
> The code in do_subassign2_dflt currently does not check that the
> replacement has length > 0 for the nsubs == 1 case.  I think we want:
> 
> 
> @@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
> SEXP rho)
>         if (nsubs == 0 || CAR(subs) == R_MissingArg)
>             error(_("[[ ]] with missing subscript"));
>         if (nsubs == 1) {
> +            if (length(y) == 0)
> +                error(_("[[ ]] replacement has zero length"));
>             offset = OneIndex(x, thesub, length(x), 0, &newname,
> recursed ? len-1 : -1, R_NilValue);
>             if (isVectorList(x) && isNull(y)) {
>                 x = DeleteOneVectorListItem(x, offset);
> 
> 
> + seth
> 
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
  (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)              FAX: (+45) 35327907

Comment 5 Jitterbug compatibility account 2010-02-21 15:07:26 UTC
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
OK. I now have a version which seems to do the trick and reuses an 
existing error message. Will commit to r-devel if and when make 
check-devel succeeds.

-p

Peter Dalgaard wrote:
> seth@userprimary.net wrote:
> 
> Thanks, Seth. Martin Morgan sent a patch for a few lines above yours, 
> which I didn't have a chance to review until now:
> 
> -   if (!isVectorList(x) && LENGTH(y) > 1)
> -       error(_("more elements supplied than there are to replace"));
> +   if (!isVectorList(x) && LENGTH(y) != 1)
> +       if (LENGTH(y) == 0)
> +           error(_("fewer elements supplied than there are to replace"));
> +       else
> +           error(_("more elements supplied than there are to replace"));
> 
> I _think_ that you are both right that there is no way for a zero-length 
> RHS not to be an error. E.g.,
> 
>  > x[[0]] <- real(0)
> Error in x[[0]] <- real(0) : attempt to select less than one element
> 
> The difference between Seth's solution and Martin's is whether to 
> pre-check for nsubs==1, and I don't think we want that because of
> 
>  > x <- matrix(1:4,2,2)
>  > x[[2,2]]
> [1] 4
>  > x[[2,2]] <- integer(0)
>  > x
>      [,1]      [,2]
> [1,]    1         3
> [2,]    2 142000760
> 
> 
>> On 2/20/10 7:50 AM, Peter Dalgaard wrote:
>>> You don't want to understand, believe me! ;-)
>>>
>>> It's a bug, probably not the very worst kind, but accessing memory that
>>> isn't yours is potentially harmful (but writing to it is considerably
>>> worse).
>>>
>>> Looks like the issue only concerns the right hand side; nothing to do
>>> with the auto-expansion of v. I also get
>>>
>>>> v <- integer(0)
>>>> u <- integer(1)
>>>> u[[2]] <-v
>>>> u
>>> [1]         0 142000760
>>>> u[[1]] <-v
>>>> u
>>> [1] 142000760 142000760
>>>> a <- 1
>>>> a[[1]] <-v
>>>> a
>>> [1] 142000760
>>
>> I'm thinking this should be an error.  Similar to:
>>
>>> v = 1
>>> v[[1]] = integer(3)
>> Error in v[[1]] = integer(3) :
>>   more elements supplied than there are to replace
>>
>> But instead not enough elements supplied.  Perhaps:
>>
>>> v[[1]] = integer()
>> Error in v[[1]] = integer() : [[ ]] replacement has zero length
>>
>> The code in do_subassign2_dflt currently does not check that the
>> replacement has length > 0 for the nsubs == 1 case.  I think we want:
>>
>>
>> @@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
>> SEXP rho)
>>         if (nsubs == 0 || CAR(subs) == R_MissingArg)
>>             error(_("[[ ]] with missing subscript"));
>>         if (nsubs == 1) {
>> +            if (length(y) == 0)
>> +                error(_("[[ ]] replacement has zero length"));
>>             offset = OneIndex(x, thesub, length(x), 0, &newname,
>> recursed ? len-1 : -1, R_NilValue);
>>             if (isVectorList(x) && isNull(y)) {
>>                 x = DeleteOneVectorListItem(x, offset);
>>
>>
>> + seth
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> 


-- 
    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
  (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)              FAX: (+45) 35327907

Comment 6 Jitterbug compatibility account 2010-02-25 17:08:00 UTC
NOTES:
 Changed for 2.11.0
Comment 7 Jitterbug compatibility account 2010-02-25 17:08:28 UTC
Audit (from Jitterbug):
Thu Feb 25 11:08:28 2010	ripley	changed notes
Thu Feb 25 11:08:28 2010	ripley	moved from incoming to Low-level-fixed
Comment 8 Jackie Rosen 2014-02-16 11:42:45 UTC
(spam comment removed)