> 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-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On
> Behalf
> Of Martin Morgan
> Sent: Saturday, December 01, 2012 6:54 AM
> To: Duncan Murdoch
> Cc: r-help@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@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@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.
______________________________________________
R-help@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.
