[R] segfault debugging

[William Dunlap]

> valgrind is usually effective for this
>
>   R -d valgrind -f myscript.R

And adding the R command
    gctorture(TRUE)
to the top of your script lets valgrind do a better job of
find memory misuse.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com


> -----Original Message-----
> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] On Behalf
> Of Martin Morgan
> Sent: Saturday, December 01, 2012 6:54 AM
> To: Duncan Murdoch
> Cc: r-help at r-project.org; Donatella Quagli
> Subject: Re: [R] segfault debugging
> 
> On 12/01/2012 04:51 AM, Duncan Murdoch wrote:
> > On 12-12-01 6:56 AM, Donatella Quagli wrote:
> >> Thank you so far. Here is an excerpt from the gdb session after a crash:
> >>    Program received signal SIGSEGV, Segmentation fault.
> >>
> >>    0xb7509a6b in Rf_allocVector () from /usr/lib/R/lib/libR.so
> >>    (gdb) backtrace
> >>    #0  0xb7509a6b in Rf_allocVector () from /usr/lib/R/lib/libR.so
> >>    #1  0xb744b64c in ?? () from /usr/lib/R/lib/libR.so
> >>    #2  0xb74c58bf in ?? () from /usr/lib/R/lib/libR.so
> >>    #3  0xb74c9c62 in Rf_eval () from /usr/lib/R/lib/libR.so
> >>    #4  0xb74ce60f in Rf_applyClosure () from /usr/lib/R/lib/libR.so
> >>    #5  0xb74c9f29 in Rf_eval () from /usr/lib/R/lib/libR.so
> >>    #6  0xb7503002 in Rf_ReplIteration () from /usr/lib/R/lib/libR.so
> >>    #7  0xb7503298 in ?? () from /usr/lib/R/lib/libR.so
> >>    #8  0xb7503812 in run_Rmainloop () from /usr/lib/R/lib/libR.so
> >>    #9  0xb7503839 in Rf_mainloop () from /usr/lib/R/lib/libR.so
> >>    #10 0x08048768 in main ()
> >>    #11 0xb728de46 in __libc_start_main (main=0x8048730 <main>, argc=8,
> >> ubp_av=0xbfdb7824, init=0x80488a0 <__libc_csu_init>,
> >>        fini=0x8048890 <__libc_csu_fini>, rtld_fini=0xb7784590,
> >> stack_end=0xbfdb781c) at libc-start.c:228
> >>    #12 0x08048791 in _start ()
> >>
> >> It seems to me that the error is in frame #0. Does it mean that there is a bug
> >> in libR.so?  What can I do next?
> >
> > It means that the error was detected when trying to do a memory allocation.
> > That could be a bug in R, but more likely something else has damaged the memory
> > management system structures, e.g. a function writing to memory that it doesn't
> > own.
> >
> > Bugs like this are hard to track down, because the damage could have occurred a
> > long time before it showed up, and small changes to your script could affect it.
> >
> > I would try to narrow it down to a single statement in your script.  You might
> > be able to deduce that from the last line printed before the crash.  If you
> > don't have any printing, you could try adding some, but as I mentioned above,
> > that might make the bug behave differently.
> >
> > Another approach is to cut off statements at the end of your script. That
> > probably won't affect the bug until you cut off the statement that actually
> > triggered it (but it might, which is why this kind of bug is so frustrating to
> > track down).
> >
> > If you find the bad statement, then look at calls to external code in it, or
> > recently executed before it.  See if any of them look like they contain errors.
> > Common errors are to write to an array without allocating it, or to write beyond
> > the bounds of an array, or (in .Call() code) to allocate something and then fail
> > to protect it from garbage collection.
> >
> > You could also figure out what the problem is that caused the seg fault in frame
> > 0.  It might be because some particular variable contains a garbage value.  Then
> > in a new run, you can ask gdb to break when that memory location takes on the
> > garbage value.  This is usually effective if you really can identify the bad
> > value, but doing that can be hard, especially when you aren't familiar with how
> > things normally work.
> 
> valgrind is usually effective for this
> 
>    R -d valgrind -f myscript.R
> 
> but it requires an operating system where it is available (e.g., linux) and a
> quick (say less than 10's of seconds) way of reproducing the bug (because
> valgrind slows evaluation alot). So the first step is really to narrow down your
> large script to something that is easier to re-run., e.g., saving the important
> R objects to a file shortly before the problem section of your script, then
> reproducing the problem by loading those and evaluating a few steps of the code.
> The bug can still be intermittent; valgrind will likely spot the problem.
> 
> Martin
> 
> >
> > Good luck!
> >
> > Duncan Murdoch
> >
> > ______________________________________________
> > 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.
> 
> 
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> 
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
> 
> ______________________________________________
> 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.