Bug in nlm, found using sem; failure in several flavors (PR#13883)
William Dunlap wrote:
From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf Of Ben Bolker Sent: Monday, August 10, 2009 12:52 PM To: r-devel at r-project.org Subject: Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883) A wild guess, based on some recent "non-deterministic" behavior in lme4: could this be driven by a bug in optimized linear algebra libraries (BLAS/LAPACK)? (Unfortunately, I'm not clear on how to check the versions of BLAS/LAPACK being used and whether they are subject to bugs, but perhaps someone else can comment ...) Ben Bolker
Running his example under valgrind (a memory misuse checker on Linux) does show it using memory it should not be using in the optimization C code around where it is copying the gradient vector. The ==10916== Invalid read of size 1 ==10916== at 0x400686D: memcpy (mc_replace_strmem.c:406) ==10916== by 0x8072BC1: FT_store (optimize.c:319) ==10916== by 0x8072F92: fcn (optimize.c:408)
...
Mmmm... This comes from this code inside fcn()
if (state->have_gradient) {
g = REAL(coerceVector(getAttrib(s, install("gradient")),
REALSXP));
if (state->have_hessian) {
h = REAL(coerceVector(getAttrib(s, install("hessian")),
REALSXP));
}
}
FT_store(n, *f, x, g, h, state);
I suppose that if the function being optimized returns a value that has
a "gradient" attribute, then that is being used. It is coerced to
double; but otherwise, no questions asked.
I wonder if it would not be a good idea to at least check that
getAttrib(....) returns something of the right length.
O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907