[Rd] R CMD build wiped my computer
Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaM? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?XtmKRinv? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?alphaL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?L? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?dev? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?astar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Worig? may be used uninitialized in this function gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c cs_add.c -o cs_add.o gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexcep
Re: [Rd] R CMD build wiped my computer
Hi Martin, I think this is the most likely reason given that the name in the DESCRIPTION file does NOT have a version number. Even so, it is very easy to misname a file and then delete it/change its name (as I've done here) and I hope current versions of R would not cause this problem. Perhaps Fedora should not use ~ as its back up file suffixes? Cheers, Jarrod On 28 Jul 2010, at 11:41, Martin Maechler wrote: Jarrod Hadfield on Tue, 27 Jul 2010 21:37:09 +0100 writes: Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, the culprit may lay here: * removing junk files unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g - pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitializ
[Rd] gcc optimization
Hi, I have noticed that the run times for MCMCglmm models (mainly written in C/C++) have suddenly jumped up on Linux machines (Ubuntu/Linaro 4.6.4 and Scientific Linux 6.6) yet they have remained stable on Windows where they run much faster than on Linux. I wondered whether something had changed with the deafult optimization flags for gcc? I am using R 3.2.3. Cheers, Jarrod -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] can't build from source: error: template with C linkage
Hi All, Users have contacted me because they can not build MCMCglmm from source. All are using R 3.3.0 on various machines with different compilers gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 Mac OS X El Capitan (version/compiler unspecified) The issue seems to be with mixing C/C++ with the repeated error: /usr/include/c++/5/bits/cpp_type_traits.h:118:3: error: template with C linkage template I see a bug report has been filed for the CRAN package tgp that was experiencing similar problems, but it is not clear whether it has been resolved. Any help would be greatly appreciated. Cheers, Jarrod -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] can't build from source: error: template with C linkage
Hi Martyn, Thanks for the help. This is now ringing very vague bells and I will check it out. Cheers, Jarrod On 19/08/16 15:51, Martyn Plummer wrote: This looks like the result of including a C++ system header inside an extern "C" block. There is no evidence of this happening in the current version 2.22.1. However, it did happen in the previous version 2.22 via the chain of inclusions: MCMCglmmcc.h -> cs.h -> R.h -> various C++ system headers See Writing R Extensions P 108. I would check that the people reporting this bug are using the latest version. If not then you have already fixed this. Martyn On Fri, 2016-08-19 at 06:25 -0500, Dirk Eddelbuettel wrote: Jarrod, On 19 August 2016 at 04:43, Jarrod Hadfield wrote: Hi All, Users have contacted me because they can not build MCMCglmm from source. All are using R 3.3.0 on various machines with different compilers gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 Mac OS X El Capitan (version/compiler unspecified) The issue seems to be with mixing C/C++ with the repeated error: /usr/include/c++/5/bits/cpp_type_traits.h:118:3: error: template with C linkage template I see a bug report has been filed for the CRAN package tgp that was experiencing similar problems, but it is not clear whether it has been resolved. Any help would be greatly appreciated. I am on Ubuntu 16.04 with gcc/g++ 5.4.0 and I _cannot_ reproduce this. Your package installs fine [1]. Dirk [1] For some definition of 'fine' which overlooks pages of compiler _warnings_. Still no errors. A log is below. Note that I a) had to turn off '- Wall -pedantic' which I normally use, and add two explicit 'do not warn' switches. The rest is stock Ubuntu behaviour. edd@max:/tmp/mcmcglmm$ R_LIBS_USER=/tmp/RcppDepends/lib R CMD INSTALL MCMCglmm_2.22.1.tar.gz R_LIBS_USER=/tmp/RcppDepends/lib R CMD INSTALL MCMCglmm_2.22.1.tar.gz * installing to library ‘/tmp/RcppDepends/lib’ * installing *source* package ‘MCMCglmm’ ... ** package ‘MCMCglmm’ successfully unpacked and MD5 sums checked ** libs gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_add.c -o cs_add.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_addR.c -o cs_addR.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_cbind.c -o cs_cbind.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_chol.c -o cs_chol.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_cholsol.c -o cs_cholsol.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_amd.c -o cs_amd.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_compress.c -o cs_compress.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_cov2cor.c -o cs_cov2cor.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitialized -Wno-unused-but-set- variable -c cs_counts.c -o cs_counts.o gcc -I/usr/share/R/include -DNDEBUG -fpic -g -O2 -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -Wall -pipe -pedantic -std=gnu99 -O3 -pipe -std=gnu99 -Wno-maybe-uninitial
[Rd] Conditional jump or move depends on uninitialised value(s)
Hi, I'm using valgrind to check over some C/C++ code for an R library. I'm getting the report (see below), but can't track down the uninitialised value(s). I tried using --track-origins=yes in valgrind which gives: ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) I presume the problem is an uninitialised value being used in my code, rather than in libRlapack, but there is a better way of tracking down where it is? Cheers, Jarrod R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" ==28258== Conditional jump or move depends on uninitialised value(s) ==28258==at 0xEE87208: dstemr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0xEE7F39B: dsyevr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0x15B23BD9: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x15B28397: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x35CA4BFEAC: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C58F9: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8ACC: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4CAEE7: ??? (in /usr/lib64/R/lib/libR.so) ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] valgrind and C++
Hi, I am sorry if this is perceived as a C++ question rather than an R question. After uploading an R library to CRAN (MCMCglmm) the C++ code failed to pass the memory checks. The errors come in pairs like: Mismatched free() / delete / delete [] at 0x4A077E6: free (vg_replace_malloc.c:446) by 0x144FA28E: MCMCglmm (MCMCglmm.cc:2184) Address 0x129850c0 is 0 bytes inside a block of size 4 alloc'd at 0x4A07CE4: operator new[](unsigned long) (vg_replace_malloc.c:363) by 0x144F12B7: MCMCglmm (MCMCglmm.cc:99) which is associated with lines allocating and freeing memory (nG is an integer): int *keep = new int [nG]; and delete [] keep; To me this looks fine, and on my machine (Scientific Linux 6.4) using gcc 4.4.7-3 and valgrind 1:3.8.1-3.2 I get no such errors. Its not clear to me which flavour of Linux or compiler the CRAN team used, although from MCMCglmm-Ex.Rout I can see the same version of valgrind was used. Any insight would be very welcome. Kind Regards, Jarrod -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind and C++
Hi Martyn,
Thanks for the email - you are right. I thought I was getting the
valgrind checks on my submission, not the version on CRAN.
Kind Regards,
Jarrod
Quoting Martyn Plummer on Tue, 18 Mar 2014 16:53:55 +:
I think the server that runs the valgrind checks is still running the
old version of your package (2.17) not the new one (2.18). Wait for an
update.
Martyn
On Mon, 2014-03-17 at 17:26 +, Jarrod Hadfield wrote:
Hi,
I am sorry if this is perceived as a C++ question rather than an R
question. After uploading an R library to CRAN (MCMCglmm) the C++ code
failed to pass the memory checks. The errors come in pairs like:
Mismatched free() / delete / delete []
at 0x4A077E6: free (vg_replace_malloc.c:446)
by 0x144FA28E: MCMCglmm (MCMCglmm.cc:2184)
Address 0x129850c0 is 0 bytes inside a block of size 4 alloc'd
at 0x4A07CE4: operator new[](unsigned long) (vg_replace_malloc.c:363)
by 0x144F12B7: MCMCglmm (MCMCglmm.cc:99)
which is associated with lines allocating and freeing memory (nG is an
integer):
int *keep = new int [nG];
and
delete [] keep;
To me this looks fine, and on my machine (Scientific Linux 6.4) using
gcc 4.4.7-3 and valgrind 1:3.8.1-3.2 I get no such errors. Its not
clear to me which flavour of Linux or compiler the CRAN team used,
although from MCMCglmm-Ex.Rout I can see the same version of valgrind
was used. Any insight would be very welcome.
Kind Regards,
Jarrod
---
This message and its attachments are strictly confiden...{{dropped:17}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rinstignore
Hi, My updated CRAN package keeps getting bounced by CRAN because the inst/doc folder is too large. I have included a .Rinstignore file in the top-level directory using both doc/Lecture1-*.*pdf$ and inst/doc/Lecture1-*.*pdf$ The files seem to be removed if I use R --as-cran CMD check package.name (I no longer get the NOTE with "checking installed package size"), but on CRAN (and if I run the check on the built tarball) the note reappears. I see this has come up before, but with no answer: http://r.789695.n4.nabble.com/R-devel-now-triggers-nags-on-notes-from-vignettes-td4324303.html Any help, would be very useful, Cheers, Jarrod -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
