Thank you for looking at this Simon. I agree it is a bug in the package and have now fixed it ( https://github.com/r-lib/fs/commit/901cb50fc2f4d25bb8b920514f52574be42d7aa5)
I will also fix the examples and submit an update to CRAN early next week. Thanks again, Jim On Mon, Mar 5, 2018 at 3:34 PM, Simon Urbanek <simon.urba...@r-project.org> wrote: > Jim, > > it’s hard to replicate anything with the package, because it’s messing > with the filesystem in random places (really, a violation of the CRAN > policy*! You should fix that as well - although running it properly would > likely hide the segfault bug ;)). Here is the stack trace: > > Process 46691 stopped > * thread #1: tid = 0x303a8b, 0x000000010262e351 > fs.so`stat_(path=<unavailable>) + 2705 at file.cc:204, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) > frame #0: 0x000000010262e351 fs.so`stat_(path=<unavailable>) + 2705 > at file.cc:204 [opt] > 201 #else > 202 group* grp; > 203 grp = getgrgid(st.st_gid); > -> 204 SET_STRING_ELT(VECTOR_ELT(out, 6), i, > Rf_mkCharCE(grp->gr_name, CE_UTF8)); > 205 #endif > 206 > 207 REAL(VECTOR_ELT(out, 7))[i] = st.st_rdev; > (lldb) bt > * thread #1: tid = 0x303a8b, 0x000000010262e351 > fs.so`stat_(path=<unavailable>) + 2705 at file.cc:204, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) > * frame #0: 0x000000010262e351 fs.so`stat_(path=<unavailable>) + 2705 > at file.cc:204 [opt] > frame #1: 0x00000001026344a6 > fs.so`::_fs_stat_(pathSEXP=0x00007f825b8ba068) > + 134 at RcppExports.cpp:73 [opt] > frame #2: 0x0000000100a003ca libR.dylib`R_doDotCall(ofun=<unavailable>, > nargs=<unavailable>, cargs=<unavailable>, call=0x00007f825b1d0eb0) + 2282 > at dotcode.c:570 [opt] > frame #3: 0x0000000100a3d71b libR.dylib`bcEval(body=<unavailable>, > rho=0x00007f825b1d1cd0, useCache=<unavailable>) + 53899 at eval.c:6962 [opt] > frame #4: 0x0000000100a2fe31 libR.dylib`Rf_eval(e=<unavailable>, > rho=<unavailable>) + 577 at eval.c:624 [opt] > > > It looks like a true bug - you’re not checking for the case where grp is > NULL (btw you have the same bug above for getpwuid). > > Cheers, > Simon > > > * - quote: > > "The code and examples provided in a package should never do anything > which might be regarded as malicious or anti-social” > […] > "Packages should not write in the user’s home filespace (including > clipboards), nor anywhere else on the file system apart from the R > session’s temporary directory (or during installation in the location > pointed to by TMPDIR: and such usage should be cleaned up).” > > > > On Feb 19, 2018, at 9:23 AM, Jim Hester <james.f.hes...@gmail.com> > wrote: > > > > I maintain the fs package, which is currently failing _only_ on CRANs > > MacOS build machine. > > <https://www.r-project.org/nosvn/R.check/r-release-osx- > x86_64/fs-00check.html> > > > > I have been trying to replicate this error and unfortunately have been > > unable to do so, the package works as expected locally (MacOS 10.12.6) > > and for numerous other people using El Capitan (as used on CRAN's > > system) <https://twitter.com/jimhester_/status/964513974942420994>. I > > also tested it on a El Capitan VM without reproducing the failure. > > > > The main difference I am aware of on CRAN's systems is the newer > > (4.0.0) clang/llvm toolchain than that shipped with XCode. I tested > > compiling / running fs with this toolchain however and did not > > reproduce the crash. > > > > If anyone has an idea of what could be causing the crash on CRAN's > > system I would be grateful. I would really like to fix this so we can > > have MacOS binaries for fs. > > > > Jim > > > > _______________________________________________ > > R-SIG-Mac mailing list > > R-SIG-Mac@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > > > [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac