From mcneney@cs.sfu.ca  Mon May 22 02:22:04 2000
From: mcneney@cs.sfu.ca (mcneney@cs.sfu.ca)
Date: Mon, 22 May 2000 03:22:04 +0200 (MET DST)
Subject: [Rd] memory problem with DEC C (was: problem with glm (PR#452))
Message-ID: <200005220122.DAA14150@pubhealth.ku.dk>

Just to update: What I originally thought was a glm problem appears to be
a memory problem that occurs only when R is compiled with the DEC C
compiler. Some variables that are still in use get clobbered during
garbage collection. No problems if I compile with gcc though. I've made
some attempts to see if I can identify a specific compiler optimization
that is responsible, but so far no luck.

Brad

On 5 Mar 2000, Peter Dalgaard BSA wrote:

> Brad McNeney <mcneney@cs.sfu.ca> writes:
> 
> > I don't know if the following is relevant, but for some reason I've found 
> > I can avoid this particular problem if I make a small change in lapply in 
> > its main loop.  Around line 50 of apply.c:
> > 
> >     PROTECT(ans = allocVector(VECSXP, n));
> >     for(i = 0; i < n; i++) {
> >         INTEGER(ind)[0] = i + 1;
> >         VECTOR(ans)[i] = eval(R_fcall, rho);
> >     }
> > 
> > if I change it to make an assignment to a
> > temporary variable first everything seems to work fine:
> > 
> >     PROTECT(ans = allocVector(VECSXP, n));
> >     for(i = 0; i < n; i++) {
> >         INTEGER(ind)[0] = i + 1;
> >         tem = eval(R_fcall, rho);
> >         VECTOR(ans)[i] = tem;
> >     }
> > 
> > hasn't given me any NULLs yet. 
> 
> Now that is pretty darn odd... Looks quite a bit like a compiler bug.
> Those two pieces of code should be equivalent as far as I can see.
> 
> One thing that you might do: objdump -dS apply.o allows you to see
> what code the compiler generates for the two cases. Also, of course,
> you can try reducing the level of optimization.
> 
> 
> Alternatively, the mere addition of "tem" changes the local memory use
> of that function so that something that got clobbered before doesn't
> get clobbered now.
> 
> The effect doesn't seem to be present on Intels:
> 
> > dfr<-do.call("data.frame",lapply(1:100,function(i)rnorm(100)))
> > any(sapply(lapply(dfr,summary),is.null))
> [1] FALSE
> 
> -- 
>    O__  ---- Peter Dalgaard             Blegdamsvej 3  
>   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
>  (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
> 


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] memory problem with DEC C (was: problem with glm (PR#452))
mcneney@cs.sfu.ca