[R] What is the meaning of "segfault 'memory not mapped' " ?
(Ted Harding)
Ted.Harding at manchester.ac.uk
Sun Oct 5 22:46:29 CEST 2008
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.
On 05-Oct-08 20:22:53, Thomas Lumley wrote:
> 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
> tlumley at u.washington.edu University of Washington, Seattle
>
> ______________________________________________
> R-help at 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.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 05-Oct-08 Time: 21:46:27
------------------------------ XFMail ------------------------------
More information about the R-help
mailing list