Based on further (off-list) follow-ups with Simon and Uwe, the situation can now be summarized as follows:
- there appears to be no word about non-leak errors reported by valgrind in the official documentation; I will have to plead that those with the power to amend these documents maybe address that one day - it has been confirmed that when such a valgrind report is present, there is no auto-processing of the package and a manual re-check is done; as a package maintainer I rather avoid that to minimize manual interventions by both the CRAN team and the package maintainer (i.e. myself) - using `VALGRIND_OPTS="-s" R -d valgrind -f nameOfTheFile.R` is helpful, especially for the test framework I use where test files are standard R scripts; this helps in locating the issue - in the case that spawned this, the error actually comes from just one test and is tickled by a third-party system library so there is nothing for us to do here, besides not to run the test - so I moved the test into a testfile matching 'test_.*_extra.R' and now exclude files with that pattern via .Rbuildignore; that gives us a fuller test surface when testing locally via the full the test directory yet permits to isolate-away tests we would rather not be running at CRAN. My thanks to everybody who helped with the question and clarified the context. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
