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 > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac