Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

plyr crashing R on Windows 64bit #110

Closed
davidcarslaw opened this Issue · 4 comments

3 participants

@davidcarslaw

Hi Hadley/Winston

I've been using plyr for several years now and use it in my package 'openair'. I am finding there is a problem with the RC version. It crashes R when used in ESS/Emacs, or the basic R GUI on 64 bit Windows, 64 bit R. It's fine in RStudio though! To reproduce:

mydata <- data.frame(groups = rep(1:10, each = 10), x = runif(100))
ddply(mydata, .(groups), numcolwise(mean))

Which brings up a dialog box "R for Windows terminal front-end has stopped working"

Note I have Rtools215.exe (which I use for compiling C++ etc. fine).

This is on R 2.15.2 64 bit with only plyr loaded. Works fine on 32 bit R.

Hope that helps?

All the best

David

@hadley
Owner

Hmmm, I suspect that's probably just a compilation mismatch error, and won't be a problem for the cran version.

@davidcarslaw

Actually, looking at the compilation there is a problem here - see 64 bit warning. However, I can't seem to avoid this situation. devtools needs to be installed, which as you say depends on plyr, so the old plyr is still there. Seems to be OK for the 32 bit compile though...any suggestions?

Installing github repo(s) plyr/plyr-1.8-rc from hadley
Installing plyr.zip from https://api.github.com/repos/hadley/plyr/zipball/plyr-1.8-rc
Installing plyr
C:/PROGRA~4/R-215~1.2/bin/x64/R --vanilla CMD build \
"C:\Users\david\AppData\Local\Temp\RtmpOk6NBb\hadley-plyr-85ca84f" --no-manual \
--no-resave-data

  • checking for file 'C:\Users\david\AppData\Local\Temp\RtmpOk6NBb\hadley-plyr-85ca84f/DESCRIPTION' ... OK
  • preparing 'plyr':
  • checking DESCRIPTION meta-information ... OK
  • cleaning src
  • checking for LF line-endings in source and make files
  • checking for empty or unneeded directories
  • looking to see if a 'data/datalist' file should be added
  • building 'plyr_1.8.tar.gz'

C:/PROGRA~4/R-215~1.2/bin/x64/R --vanilla CMD INSTALL \
"C:\Users\david\AppData\Local\Temp\RtmpOk6NBb/plyr_1.8.tar.gz" \
--library="C:/ProgramFiles/R-2.15.2/library" --with-keep.source

  • installing source package 'plyr' ... ** libs

*** arch - i386
gcc -I"C:/PROGRA~4/R-215~1.2/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -c loop-apply.c -o loop-apply.o
gcc -I"C:/PROGRA~4/R-215~1.2/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=core2 -c split-numeric.c -o split-numeric.o
gcc -shared -s -static-libgcc -o plyr.dll tmp.def loop-apply.o split-numeric.o -LC:/PROGRA~4/R-215~1.2/bin/i386 -lR
installing to C:/ProgramFiles/R-2.15.2/library/plyr/libs/i386

*** arch - x64
gcc -m64 -I"C:/PROGRA~4/R-215~1.2/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall -std=gnu99 -mtune=core2 -c loop-apply.c -o loop-apply.o
gcc -m64 -I"C:/PROGRA~4/R-215~1.2/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall -std=gnu99 -mtune=core2 -c split-numeric.c -o split-numeric.o
gcc -m64 -shared -s -static-libgcc -o plyr.dll tmp.def loop-apply.o split-numeric.o -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/PROGRA~4/R-215~1.2/bin/x64 -lR
installing to C:/ProgramFiles/R-2.15.2/library/plyr/libs/x64
Warning in file.copy(files, dest, overwrite = TRUE) :
problem copying .\plyr.dll to C:\ProgramFiles\R-2.15.2\library\plyr\libs\x64\plyr.dll: Permission denied
** R
** data
** moving datasets to lazyload DB
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
*** arch - i386
*** arch - x64

  • DONE (plyr)
@davidcarslaw

Sorry for the traffic!. Got it working by building from source and installing myself. Just might be an issue to look out for...

@wch
Collaborator

@DCCKC It's possible that the crashing was happening because of a bug in some of plyr's C code that is now fixed. The bug seemed to only manifest on some platforms and even then, not every time.

It should be fixed in 03e1af8.

@hadley hadley closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.