[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


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