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.hester at gmail.com>
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