[R-SIG-Mac] Replication runtime error on MacOS build machines

[Simon Urbanek]

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> 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 at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>