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

[Jim Hester]

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.urbanek at 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.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
> >
>
>

	[[alternative HTML version deleted]]