[R] What is the meaning of "segfault 'memory not mapped' " ?

[Ubuntu.Diego]

I'm trying to get some "easy coding" to reproduce the error. In the
meantime I have R code that run for 20 or more hours and suddenly i got
a "segfault 'memory not mapped'" error. I have to clarify that the error
not alway occurs and sometimes the process end satisfactorily. The
process is basically a search using an MCMC strategy, sometimes the
algorithm converge and stops others I got the error message. I was
wondering if it could be meaning that I run out of RAM.
Thanks

PS: I don't want to submit code that maybe after 48 hours of running
still don't generate the error.

______________________________________________
R-h...@r-project.org 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.

[Ben Bolker]

Ubuntu.Diego <ubuntu.diego <at> gmail.com> writes:

>
> I'm trying to get some "easy coding" to reproduce the error. In the
> meantime I have R code that run for 20 or more hours and suddenly i got
> a "segfault 'memory not mapped'" error. I have to clarify that the error
> not alway occurs and sometimes the process end satisfactorily. The
> process is basically a search using an MCMC strategy, sometimes the
> algorithm converge and stops others I got the error message. I was
> wondering if it could be meaning that I run out of RAM.
> Thanks
>
> PS: I don't want to submit code that maybe after 48 hours of running
> still don't generate the error.
>

that makes sense ...

We need more information about what you are trying to do,
what packages you're using, etc.. In general a segfault means
a bug -- in R if the functions you're using are base R, but
more likely in C code that you wrote or that comes from
a contributed package (since the C code in R has been
pretty thoroughly hammered on, it's much less likely -- although
not impossible -- that it contains a memory bug like this).
If you're using C code you wrote yourself, it's almost
certainly in there.

Can you tell us what functions you were using,
results of sessionInfo, etc. ?

If it's your own code or if you're feeling adventurous
you can try to use valgrind to locate the problem --
see

http://finzi.psych.upenn.edu/R/Rhelp02a/archive/124215.html

for a start, or the R Extensions manual ...

Ben Bolker

[Peter Dalgaard]

Also, some information on the system in question would be in order. I
hazard a guess at Ubuntu, but if so, he hid it quite well...

In general, "memory not mapped" means that you are trying to access a
memory address which isn't in your process. Typically by failing to
allocate memory and trying to use it anyway, but it could also happen by
accidentally overwriting a pointer.

--
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.dal...@biostat.ku.dk) FAX: (+45) 35327907

[Thomas Lumley]

On Fri, 3 Oct 2008, Ubuntu.Diego wrote:
> I'm trying to get some "easy coding" to reproduce the error. In the
> meantime I have R code that run for 20 or more hours and suddenly i got
> a "segfault 'memory not mapped'" error. I have to clarify that the error
> not alway occurs and sometimes the process end satisfactorily. The
> process is basically a search using an MCMC strategy, sometimes the
> algorithm converge and stops others I got the error message. I was
> wondering if it could be meaning that I run out of RAM.

The 'memory not mapped' error means that your code is reading from or
writing to memory that it doesn't own. This should have nothing to do with
running out of RAM.

If this is pure R code you have found a bug in R. If you are calling your
own C code it is more likely to be a bug there. If your C code uses
PROTECT/UNPROTECT it is even more likely to be there.

Usually the best way to track down these bugs is to run the code under
Valgrind, but this is slow, which will be a problem for code that already
takes many hours.

If you are extremely lucky, the crash will have happened on the first
incorrect memory access. Running R under a debugger such as gdb you can
use backtrace after the crash occurs to find where the bug happened.
Unfortunately it is quite likely that the crash happened because some
earlier piece of code overwrote a stored variable or something similar.
The fact that the segfault occurs only some of the time reinforces this,
especially if you don't always get the crash even with the same sequence
of random numbers.

If you have a Linux computer that you can use for a week or so it would be
worth running your code under Valgrind to see if it finds the problem.

-thomas

Thomas Lumley Assoc. Professor, Biostatistics
tlu...@u.washington.edu University of Washington, Seattle

[Ted Harding]

One thing I have often done with code (including C and R) that
falls through the ice unexpectedly is to plant (as a temporary
measure) "debug prints" which emit information about where they
are in the program, how many times they have gone round a particular
loop, values of any potentially suspect variables, etc.

Then you can look at the tail end of what they print and begin to
localise the place where things go wrong. Having approximately
located it, one can then replace the debug prints with more
narrowly focussed ones. Often, just a few at a time will work fine.

One can often wrap such a print into a function. Exactly how it
is best done depends on how the code is written, and on what
seems to be going wrong.

Hoping this helps,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.H...@manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 05-Oct-08 Time: 21:46:27
------------------------------ XFMail ------------------------------