William Dunlap wrote:
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Ben Bolker
Sent: Monday, August 10, 2009 12:52 PM
To: r-devel@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.dalga...@biostat.ku.dk) FAX: (+45) 35327907
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
