[Rd] Ways to catch segfaults before they happen
Prof Brian Ripley
ripley at stats.ox.ac.uk
Fri Nov 5 14:01:29 CET 2004
Those of you who monitor the daily package checks will know that some
packages generate ERROR reports spasmodically. This is normally due to
segfaults, and in almost all cases has been traced (eventually) to memory
access errors using the tool valgrind (http://valgrind.kde.org).
Current examples include RCurl, RandomFields, geoR, kza and pcurve.
This week I have run all the examples in all the CRAN packages under
valgrind (which took about 120 hours, not all running to completion), and
have sent reports to quite a few package maintainers. A good selection of
the reports will be available at
http://www.stats.ox.ac.uk/pub/bdr/Rvg
for the next week or so. Valgrind is not infallible and sometimes gets
confused by highly optimized code (and these tests were run with -O2): I
reckon this is the case for the loess_raw reports.
`Writing R Extensions' in 2.0.1 will have a section on `writing portable
packages' covering this, and R-devel has a R CMD check --use-valgrind
option to run all the examples/tests/vignettes under valgrind -- beware
that is typically 20x slower.
Another problem area is running packages on 64-bit platforms, and quite a
few package maintainers have received reports about that (and many have
updated their packages already, thank you). I am aware of problems
currently in
AnalyzeFMRI CoCo PBSmapping assist dblcens gap haplo.stats odesolve
sampfling subselect
some of which result in infinite loops and others in segfaults.
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel
mailing list