Skip to content

Side-effects of require() vs library() on x86_64 aka amd64

7 messages · Dirk Eddelbuettel, Peter Dalgaard, Seth Falcon

Original
Dirk Eddelbuettel
# 
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
2 days later
Dirk Eddelbuettel
#
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
Seth Falcon
# 
Hi Dirk,
* On 2009-01-30 at 22:38 -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.

+ seth
Dirk Eddelbuettel
# 
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
Peter Dalgaard
#
Dirk Eddelbuettel wrote:
Not really (and you know where to find the sources...). But sometimes it 
only takes one memory allocation more or less to shift the effect of a 
memory bug to a completely different point in space an time.
Seth Falcon
#
* On 2009-01-31 at 09:34 -0600 Dirk Eddelbuettel wrote:
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
Dirk Eddelbuettel
# 
Hi Peter,
On 31 January 2009 at 16:55, Peter Dalgaard wrote:
| Not really (and you know where to find the sources...).

Yes, and I had dug through that in the past for littler and other embedding
work.  I was just wondering if I had missed any documentation, besides the
few lines about --slave from the help page, --help switch and intro manual.

| But sometimes it 
| only takes one memory allocation more or less to shift the effect of a 
| memory bug to a completely different point in space an time.

That seems to have been the case. It also didn't help that x86 didn't trigger
it, or I would have noticed sooner after my 0.1.0 release.  Building on
different architectures help shaking these things out.

Dirk