[R] Spare some CPU cycles for testing lme?

[Douglas Bates]

Prof Brian D Ripley wrote:
> As others have said, this needs tools not CPU cycles: gctorture or valgrind.
> 
> Valgrind found (after a few seconds and on the first pass)
> 
> ==23057== Invalid read of size 4
> ==23057==    at 0x3CF4E645: ssc_symbolic_permute (Mutils.c:373)
> ==23057==    by 0x3CF5BF75: ssclme_create (ssclme.c:168)
> ==23057==    by 0x80AF5E8: do_dotcall
> (/users/ripley/R/svn/R-devel/src/main/dotcode.c:640)
> ==23057==    by 0x80CFA84: Rf_eval
> (/users/ripley/R/svn/R-devel/src/main/eval.c:399)
> ==23057==  Address 0x3C7F3BD0 is 4 bytes before a block of size 524 alloc'd
> ==23057==    at 0x3C01CB56: calloc (in
> /opt/local/lib/valgrind/vgpreload_memcheck.so)
> ==23057==    by 0x80F9EBE: R_chk_calloc
> (/users/ripley/R/svn/R-devel/src/main/memory.c:2151)
> ==23057==    by 0x3CF4E515: ssc_symbolic_permute (Mutils.c:352)
> ==23057==    by 0x3CF5BF75: ssclme_create (ssclme.c:168)
> ==23057==
> ==23057== Use of uninitialised value of size 8
> ==23057==    at 0x80C0137: Rf_duplicate
> (/users/ripley/R/svn/R-devel/src/main/duplicate.c:160)
> ==23057==    by 0x80BFA85: Rf_duplicate
> (/users/ripley/R/svn/R-devel/src/main/duplicate.c:101)
> ==23057==    by 0x80BFEB3: Rf_duplicate
> (/users/ripley/R/svn/R-devel/src/main/duplicate.c:154)
> ==23057==    by 0x816ED96: do_subset2_dflt
> (/users/ripley/R/svn/R-devel/src/main/subset.c:816)
> ==23057==
> ==23057== Conditional jump or move depends on uninitialised value(s)
> ==23057==    at 0x3CF62229: ssclme_fitted (ssclme.c:1587)
> ==23057==    by 0x80AF646: do_dotcall
> (/users/ripley/R/svn/R-devel/src/main/dotcode.c:646)
> ==23057==    by 0x80CFA84: Rf_eval
> (/users/ripley/R/svn/R-devel/src/main/eval.c:399)
> ==23057==    by 0x80D1D80: do_set
> (/users/ripley/R/svn/R-devel/src/main/eval.c:1280)
> 
> which is pretty definitive evidence of a problem (possibly 2) in the code.
> 
> I strongly recommend valgrind (http://valgrind.kde.org/) if you are using
> x86 Linux.  It has found quite a few errors in R and in certain packages
> recently.  The only thing to watch is that optimized BLASes will probably
> crash it.
> 

You're right.  I had (at least) two thinko's in that code.  The problems 
show up in the lme4 package but the errors in the C code are in the 
Matrix package.  I will upload a repaired version of the Matrix package.