Array over-runs in CRAN packages

[Prof Brian Ripley]

About 15 CRAN packages are now showing segfaults/hangs in both 
R-patched and R-devel, seen at (some columns of) 
http://cran.r-project.org/web/checks/check_summary.html .  These were 
uncovered by a change to reduce the copying of arguments in .C and 
.Fortran calls, and include packages

DoseFinding FracSim adehabitat[TL] dcemriS4 dynaTree lmm monomvn 
timereg

Some of these, e.g. FracSim, dynaTree, lmm, having been showing 
intermittent crashes for a long time (and we have reported the exact 
problem in FracSim before).

We wrote some code (currently enabled in R-devel by compiling 
src/main/dotcode.c with -DALWAYS_COPY, but that will change) to detect 
array over-runs, by adding guard elements and checking if these were 
changed.  This shows

DiceOptim.out:  array over-run in .C("improvedLHS_C") in integer 
argument 7
DoseFinding.out:    array over-run in .C("critfunc") in double 
argument 3
FracSim.out:  array over-run in .C("core_2d") in double argument 7
GLDEX.out:  array over-run in .Fortran("halton") in integer argument 4
KrigInv.out:  array over-run in .C("maximinLHS_C") in integer argument 
7
SAPP.out:  array over-run in .Fortran("momorif") in double argument 15
SpatialExtremes.out:  array over-run in .C("latentgev") in double 
argument 26
adehabitat.out:  array over-run in .C("testindepangl") in double 
argument 1
adehabitatLT.out:  array over-run in .C("testindepangl") in double 
argument 1
cts.out:  array over-run in .Fortran("setupdate") in double argument 1
dcemriS4.out:  array over-run in .C("dce_bayes_run_single") in double 
argument 11
dynaTree.out:  array over-run in .C("dynaTree_R") in integer argument 
3
fOptions.out:  array over-run in .Fortran("halton") in integer 
argument 4
ftnonpar.out:  array over-run in .C("mintvmon") in integer argument 3
lhs.out:  array over-run in .C("improvedLHS_C") in integer argument 7
lmm.out:  array over-run in .Fortran("fastmcmc") in integer argument 
48
medAdherence.out:  array over-run in .C("csa") in integer argument 5
ncomplete.out:  array over-run in .Fortran("ncompl") in integer 
argument 9
negenes.out:  array over-run in .C("R_negenes") in integer argument 12
noverlap.out:  array over-run in .Fortran("novrlp") in integer 
argument 9
randtoolbox.out:  array over-run in .Fortran("halton") in integer 
argument 4
rrcov.out:  array over-run in .Fortran("fsada") in integer argument 14
timereg.out:  array over-run in .C("score") in double argument 29

As this is experimental code I am not yet 100% sure that it is always 
correct, but I have confirmed enough examples to have some confidence 
in it.  (It is also possible the compiled code is not in your package: 
Mr lhs please note this for DiceOptim and KrigInv: however it does 
seem that there are 3 copies of the incorrect Halton code.)

Because of the way allocations work in R (rounding up to a multiple of 
8 bytes) you may get away with over-run-by-one errors for integer and 
logical arguments.  But otherwise running an instrumented version of R 
under valgrind will help pinpoint where your code steps out of bounds.

Please investigate and submit a corrected update.

Brian Ripley

-- 
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