memory problem with DEC C (was: problem with glm (PR#452))

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