R help - Nov 2006 - segfault 'memory not mapped', dual core problem?

I encountered a segfault running glm() and wonder if it could have
something to do with the way memory is handled in a dual core system
(which I just set up).  I'm running R-base-2.4.0-1, installed from the
SuSE 10.1 x86_64 rpm (obtained from CRAN).   (My processor is an AMD
Athlon 64 x2 4800+).

The error and traceback are

*** caught segfault ***
address 0x8001326f2b, cause 'memory not mapped'

Traceback:
 1: any(is.na(varmu))
 2: glm.fit(x = X, y = Y, weights = weights, start = start, etastart etastart,  
mustart = mustart, offset = offset, family = family,
control = control,     intercept = attr(mt, "intercept") > 0)
 3: glm(y ~ x, family = binomial("logit"), data = da)
 4:  ...

Note that this does NOT happen every time I make this call to glm().  
I'm calling glm() in a loop and it executed correctly many times. 

The seqfault occurred while I was running two instances of R (in
separate Linux processes), so both cores were being utilized.  Free
memory exceeded the swap memory in use, so I don't think that there was
a lot of swapping going on.

Any thoughts on what might have caused this to happen - and  how to
avoid it - would be appreciated.

thanks,

bw

I had a similar problem, but with the silhouette() function.

I figured that the function expected that the grouping variable  
started from 1, ie., if for some reason on my obs I didn't have any  
observation on group 1, the function would return me random numbers  
and repeated execution of the code would cause a seg. fault.

My fix was to remap my group variable so that it would always start  
from 1.

Maybe something like this is happening with you?

cheers,
b

On Nov 12, 2006, at 3:05 PM, Barnet Wagman wrote:
> I encountered a segfault running glm() and wonder if it could have
> something to do with the way memory is handled in a dual core system
> (which I just set up).  I'm running R-base-2.4.0-1, installed from the
> SuSE 10.1 x86_64 rpm (obtained from CRAN).   (My processor is an AMD
> Athlon 64 x2 4800+).
>
> The error and traceback are
>
> *** caught segfault ***
> address 0x8001326f2b, cause 'memory not mapped'
>
> Traceback:
>  1: any(is.na(varmu))
>  2: glm.fit(x = X, y = Y, weights = weights, start = start, etastart >
etastart,     mustart = mustart, offset = offset, family = family,
> control = control,     intercept = attr(mt, "intercept") > 0)
>  3: glm(y ~ x, family = binomial("logit"), data = da)
>  4:  ...
>
> Note that this does NOT happen every time I make this call to glm().
> I'm calling glm() in a loop and it executed correctly many times.
>
> The seqfault occurred while I was running two instances of R (in
> separate Linux processes), so both cores were being utilized.  Free
> memory exceeded the swap memory in use, so I don't think that there  
> was
> a lot of swapping going on.
>
> Any thoughts on what might have caused this to happen - and  how to
> avoid it - would be appreciated.
>
> thanks,
>
> bw
>
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting- 
> guide.html
> and provide commented, minimal, self-contained, reproducible code.

Barnet Wagman <bw at northbranchlogic.com> writes:
> I encountered a segfault running glm() and wonder if it could have
> something to do with the way memory is handled in a dual core system
> (which I just set up).  I'm running R-base-2.4.0-1, installed from the
> SuSE 10.1 x86_64 rpm (obtained from CRAN).   (My processor is an AMD
> Athlon 64 x2 4800+).
> 
> The error and traceback are
> 
> *** caught segfault ***
> address 0x8001326f2b, cause 'memory not mapped'
> 
> Traceback:
>  1: any(is.na(varmu))
>  2: glm.fit(x = X, y = Y, weights = weights, start = start, etastart >
etastart,     mustart = mustart, offset = offset, family = family,
> control = control,     intercept = attr(mt, "intercept") > 0)
>  3: glm(y ~ x, family = binomial("logit"), data = da)
>  4:  ...
> 
> Note that this does NOT happen every time I make this call to glm().  
> I'm calling glm() in a loop and it executed correctly many times. 
> 
> The seqfault occurred while I was running two instances of R (in
> separate Linux processes), so both cores were being utilized.  Free
> memory exceeded the swap memory in use, so I don't think that there was
> a lot of swapping going on.
> 
> Any thoughts on what might have caused this to happen - and  how to
> avoid it - would be appreciated.
It's highly unlikely that the dual core has anything to do with it
unless your system is overheating or has a hardware problem.

Instead, see if you can create a script that reproduces the issue (if
random numbres are involved, use set.seed) and/or run R with the -d
gdb switch on and see if you can get a traceback.

-- 
   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