[Rd] file.copy(src, src, recursive=TRUE) causes a segfault (Was: Re: R CMD check . segfault on re-building vignettes)

[Henrik Bengtsson]

It appears that file.copy() does not protect against the case when one
copies one directory to a subdirectory of itself resulting in it
trying to create and endless recursive copy of itself.

REPRODUCIBLE EXAMPLE:
src <- "foo"
dir.create(src);
file.copy(src, src, recursive=FALSE) # ok
file.copy(src, src, recursive=TRUE) # PROBLEM
file.exists("foo/foo/foo/foo/foo/foo/foo/foo/") # TRUE
file.exists("foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/") # TRUE

I can reproduce this.

TROUBLESHOOTING:
On R version 2.15.0 (2012-03-30) [Platform: x86_64-pc-linux-gnu (64-bit)] I get

> file.copy(src, src, recursive=TRUE) # endless creation/loop
Error: segfault from C stack overflow

but return to a working prompt.  BTW, this follow up causes an R error:

> dirs <- list.files("foo", recursive=TRUE)
Error: C stack usage is too close to the limit

> dirs <- system("ls -R foo/ | tail -1", intern=TRUE)
> nchar(dirs)
[1] 2512
> str(strsplit(dirs, split="/"))
List of 1
 $ : chr [1:628] "foo" "foo" "foo" "foo" ...

I guess a possible cause for the segfault is what is hinted at by the
list.files() error; internally there is a write buffer overflow due to
a too long path.

On Windows, i.e. R version 2.15.0 Patched (2012-04-25 r59178)
[Platform: x86_64-pc-mingw32/x64 (64-bit)], I get:

> file.copy(src, src, recursive=TRUE)
[1] TRUE
Warning message:
In file.copy(src, src, recursive = TRUE) :
  problem creating directory
.\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo\foo:
No such file or directory

Here the maximum file path length of the OS is probably kicking in
before reaching the buffer overflow, cf.
http://aroma-project.org/howtos/UseLongFilenamesOnWindows

My $.02

/Henrik

On Mon, Apr 30, 2012 at 8:48 AM, Sebastian Meyer
<Sebastian.Meyer at ifspm.uzh.ch> wrote:
> (Warning: There is some potential that this message is redundant.)
>
> I think that i have spotted an issue with R CMD check that does not
> trace back to a rare case, so it must have been reported already or i am
> doing something stupid. However, to be sure and because I did not find
> any comments on this while searching the R mailing lists, here is what i
> did:
>  R CMD check .
> from within a package source directory which has some vignettes in
> inst/doc. When the check finally comes to
> "checking re-building of vignette PDFs ..."
> i get the following error
>
>  *** caught segfault ***
> address 0x7fff6073c998, cause 'memory not mapped'
>
> Traceback:
>  1: file.copy(pkgdir, vd2, recursive = TRUE)
>  2: run_vignettes(desc)
>  3: check_pkg(pkgdir, pkgname, pkgoutdir, startdir, libdir, desc,
> is_base_pkg, is_rec_pkg, thispkg_subdirs, extra_arch)
>  4: tools:::.check_packages()
> aborting ...
> Segmentation fault (core dumped)
>
> as one can see, the error stems from the call
> file.copy(pkgdir, vd2, recursive = TRUE)
> in the run_vignettes function defined in the tools:::.check_packages
> function. this call will copy the contents of "pkgdir" (the source
> directory) to the ..Rcheck/vign_test/ directory _recursively_, the
> problem of which being that the "..Rcheck" directory is part of
> "pkgdir". Thus we get into a loop of copying pkgdir into
> pkgdir/..Rcheck/vign_test, which is interrupted at some point by a
> segfault (at least on my x86_64 GNU/Linux machine running Ubuntu 12.04
> and R 2.15.0; the OS might be crucial for this issue).
>
> I can reproduce the error by e.g.:
>
>  pkgdir <- tempdir()
>  file.create(file.path(pkgdir,"DESCRIPTION"))    # not necessary
>  vd2 <- file.path(pkgdir,"..Rcheck/vign_test")
>  dir.create(vd2, recursive=TRUE)
>  ### Better Do NOT run -> buffer overflow
>  # file.copy(pkgdir, vd2, recursive=TRUE)
>  ###
>
> Can anybody confirm this problem? Of course, a workaround is to run R
> CMD check from outside the source directory (which is probably the
> preferred way).
>
> Thanks in advance,
> Sebastian
>
>
> --
> Sebastian Meyer
> Division of Biostatistics
> Institute of Social and Preventive Medicine
> University of Zurich
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel