R devel - Jan 2009 - Side-effects of require() vs library() on x86_64 aka amd64

RDieHarder fails its regression tests on x86_64 (aka "amd64") at CRAN
(using
Debian), and I see the same on Ubuntu 8.10 in 64 bit.  No issues on 32bit.

One odd thing is that the program behaves well if run via

    R --no-save < tests/RDieHarder.R

but NOT when started using 

    R --slave < tests/RDieHarder.R

as R CMD check does.

So I tried different things related to startup options, --vanilla, etc pp. No
luck, no change.  And I just poked around with gdb, valgrind, ... without
much luck until I noticed that

   echo 'library(RDieHarder); dh <- dieharder("rand",
"runs", seed=12345); \
   	 print(summary(dh))' | R --slave

works whereas the test fails if run as encoded in tests/RDieHarder.R, ie as, 

   echo 'require(RDieHarder, quiet=TRUE); dh <-
dieharder("rand", "runs", seed=12345); \
   	 print(summary(dh))' | R --slave

[ What actually happens is that the right result gets computed either way by
DieHarder (as verbose=TRUE shows), but incorrect data gets returned to R for
subsequent tests by R ]

So what side-effects does require() have that library() does not have ?  

How can I make my package robust to this side-effect?

Thanks for any pointers, Dirk

-- 
Three out of two people have difficulties with fractions.

On 28 January 2009 at 22:26, Dirk Eddelbuettel wrote:
| 
| RDieHarder fails its regression tests on x86_64 (aka "amd64") at
CRAN (using
| Debian), and I see the same on Ubuntu 8.10 in 64 bit.  No issues on 32bit.
| 
| One odd thing is that the program behaves well if run via
| 
|     R --no-save < tests/RDieHarder.R
| 
| but NOT when started using 
| 
|     R --slave < tests/RDieHarder.R
| 
| as R CMD check does.

Turns out, as so often, that there was a regular bug lurking which is now
fixed in RDieHarder 0.1.1.  But I still would like to understand exactly what
is different so that --slave was able to trigger it when --vanilla,
--no-save, ... did not.  

[ The library() vs require() issue may have been a red herring. ]

Dirk

-- 
Three out of two people have difficulties with fractions.

Hi Dirk,

* On 2009-01-30 at 22:38 -0600 Dirk Eddelbuettel wrote:
> Turns out, as so often, that there was a regular bug lurking which is now
> fixed in RDieHarder 0.1.1.  But I still would like to understand exactly
what
> is different so that --slave was able to trigger it when --vanilla,
> --no-save, ... did not.  
> 
> [ The library() vs require() issue may have been a red herring. ]
Without telling us any details about the nature of the bug you found,
it is difficult to speculate.  If the bug was in your C code and
memory related, it could simply be that the two different run paths
resulted in different allocation patterns, one of which triggered the
bug.

+ seth

-- 
Seth Falcon | http://userprimary.net/user/

Hi Seth,

Thanks for the follow-up.

On 31 January 2009 at 06:59, Seth Falcon wrote:
| * On 2009-01-30 at 22:38 -0600 Dirk Eddelbuettel wrote:
| > Turns out, as so often, that there was a regular bug lurking which is now
| > fixed in RDieHarder 0.1.1.  But I still would like to understand exactly
what
| > is different so that --slave was able to trigger it when --vanilla,
| > --no-save, ... did not.  
| > 
| > [ The library() vs require() issue may have been a red herring. ]
| 
| Without telling us any details about the nature of the bug you found,
| it is difficult to speculate.  If the bug was in your C code and
| memory related, it could simply be that the two different run paths
| resulted in different allocation patterns, one of which triggered the
| bug.

Yes yes and yes :)  It was in C, and it was memory related and it dealt
getting results out of the library to which the package interfaces. 

But short of looking at the source, is there any documentation on what
--slave does differently?

Dirk

-- 
Three out of two people have difficulties with fractions.

* On 2009-01-31 at 09:34 -0600 Dirk Eddelbuettel wrote:
> | Without telling us any details about the nature of the bug you found,
> | it is difficult to speculate.  If the bug was in your C code and
> | memory related, it could simply be that the two different run paths
> | resulted in different allocation patterns, one of which triggered the
> | bug.
> 
> Yes yes and yes :)  It was in C, and it was memory related and it dealt
> getting results out of the library to which the package interfaces. 
> 
> But short of looking at the source, is there any documentation on what
> --slave does differently?
The R-intro manual has a brief description:

--slave
    Make R run as quietly as possible. This option is intended to
    support programs which use R to compute results for them. It
    implies --quiet and --no-save.

I suspect that for more detail than that, one would have to look at
the sources.  But the above helps explain the behavior you saw; a
"--quite" R will suppress some output and that will make a difference
in terms of memory allocation.

+ seth

-- 
Seth Falcon | http://userprimary.net/user/