Your "mocking" phrase in unknown to me. I am not sure where to trace that down. Read the bash script for check? Read tools:::.check_packages? Both are clear as mud to me.
Also I just tried debugging by print statements. That does not work. It leaves the C called just before the crash. Putting a cat statement in the R function that calls the C function prevents the crash. I know. If there is memory corruption, doing anything can change the crash behavior. So that is not mystifying. Just frustrating. On Sat, Jul 4, 2015 at 10:48 AM, Dirk Eddelbuettel <e...@debian.org> wrote: > > Agreed on divide-and-conquer. There is no other way. Valgridn et al may > move > some code to registers for subtle changes. > > On 4 July 2015 at 10:20, Charles Geyer wrote: > | I should add a more direct question. When a crash occurs ONLY when > running R > | CMD check, how does one debug that? Usually one would say that R CMD > check > | --use-valgrind > | is the answer. But it only segfaults when --use-vagrind is not used. So > | somehow we have to debug R CMD check itself. How? > > By "mocking" the exact same (compile and run-time) options used by R CMD > check. You can trace that down. Things depend a little on whether you do > or > do not use user-library-paths for .libPaths() or not, whether you use > per-user compile flags etc pp. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
