From p.dalgaard at biostat.ku.dk  Tue Aug 11 00:17:34 2009
From: p.dalgaard at biostat.ku.dk (Peter Dalgaard)
Date: Tue, 11 Aug 2009 00:17:34 +0200
Subject: [Rd] Bug in nlm, found using sem;
 failure in several flavors (PR#13883)
In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D70001A18B3C@NA-PA-VBE03.na.tibco.com>
References: <20090807223514.7C78E282EF4C@mail.pubhealth.ku.dk>	<24906063.post@talk.nabble.com>
	<77EB52C6DD32BA4D87471DCD70C8D70001A18B3C@NA-PA-VBE03.na.tibco.com>
Message-ID: <4A809C7E.5030509@biostat.ku.dk>

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



[Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)
Peter Dalgaard