On 04/24/2015 06:49 AM, Franckx Laurent wrote:
Dear all
I have bumped into the dreaded 'segfault' error type when running some C++
code using .Call().
segfaults often involve invalid memory access at the C level that are best
discovered via valgrind or similar rather than gctorture. A good way to spot
these is to
(a) come up with a _minimal_ reproducible script test.R that takes just a few
seconds to run and that tickles, at least some times, the segfault
(b) make sure that your package is compiled without optimizations and with
debugging symbols, e.g., in ~/.R/Makevars add the lines
CFLAGS="-ggdb -O0"
CXXFLAGS="-ggdb -O0"
(c) run the code under 'valgrind'
R -d valgrind -f test.r
Look especially for 'invalid read' or 'invalid write' messages, and isolate
_your_ code in the callback that the message produces.
There is a 'worked example' at
http://bioconductor.org/developers/how-to/c-debugging/#case-study
Of course this might lead to nothing, and then you'll be back to your original
question about using gctorture or other strategies.
Martin Morgan
I have already undertaken several attempts to debug the C++ code with gdb(),
but until now I have been unable to pinpoint the origin of the problem. There
are two elements that I think are puzzling (a) this .Call() has worked fine
for about three years, for a variety of data (b) the actual crash occurs at
random points during the execution of the function (well, random from a human
eye's point of view).
From what I understand in the "R extensions" manual, the actual problem may
have been around for a while before the actual call to the C++ code. As
recommended in the manual, I am now using gctorture() to try to pinpoint
the origins of the problem. I can, alas, only confirm that gctorture() has
an enormous impact on execution time, even for operations that are normally
executed within the blink of an eye. From what I have seen until now,
executing all the R code before the crash with gctorture(TRUE) could take
months.
I suppose then that the best way to proceed would be to proceed backward from
the point where the crash occurs when gctorture(FALSE).
I have tried to find some concrete examples of good practices in the use of
gctorture() to identify memory problems in R, but most of what I have found
on the web is simply a copy of the help page. Does anybody know more concrete
and elaborated examples that could give an indication on how to best proceed
further?
Laurent Franckx, PhD Senior researcher sustainable mobility VITO NV |
Boeretang 200 | 2400 Mol Tel. ++ 32 14 33 58 22| mob. +32 479 25 59 07 |
Skype: laurent.franckx | laurent.fran...@vito.be | Twitter @LaurentFranckx
VITO Disclaimer: http://www.vito.be/e-maildisclaimer
______________________________________________ R-help@r-project.org mailing
list -- To UNSUBSCRIBE and more, see
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 -- To UNSUBSCRIBE and more, see
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.
