Using 'valgrind', along with gctorture(TRUE) can help track down these
bugs. E.g.
% R --debugger valgrind
==8445== Memcheck, a memory error detector
==8445== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8445== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8445== Command: /home/R/R-3.3.1/lib/R/bin/exec/R
... bunch of warnings from dl-load, etc., at startup ...
> library(Rcpp)
> cppFunction("IntegerVector runif_int2() { return
wrap(floor(runif(1000000))); }")
> set.seed(1)
> gctorture(TRUE)
> z <- runif_int2()
> z <- runif_int2()
==8445== Invalid read of size 8
==8445== at 0x4ED9465: Rf_coerceVector (coerce.c:495)
==8445== by 0x100A3191: SEXPREC*
Rcpp::internal::basic_cast<13>(SEXPREC*) (r_cast.h:58)
==8445== by 0x100A1AD7: runif_int2() (r_cast.h:67)
==8445== by 0x100A1F85: sourceCpp_1_runif_int2 (file20fd25662b99.cpp:16)
==8445== by 0x4F0BD17: do_dotcall (dotcode.c:1251)
==8445== by 0x4F4C2BA: Rf_eval (eval.c:713)
==8445== by 0x4F4D646: Rf_applyClosure (eval.c:1134)
==8445== by 0x4F4BE9E: Rf_eval (eval.c:732)
==8445== by 0x4F4F68D: do_set (eval.c:2196)
==8445== by 0x4F4C0C2: Rf_eval (eval.c:685)
==8445== by 0x4F730E1: Rf_ReplIteration (main.c:258)
==8445== by 0x4F73430: R_ReplConsole (main.c:308)
==8445== Address 0x115ea048 is not stack'd, malloc'd or (recently) free'd
==8445==
*** caught segfault ***
address 0x115ea048, cause 'memory not mapped'
Traceback:
1: .Primitive(".Call")(<pointer: 0x100a1f40>)
2: runif_int2()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
==8445==
==8445== HEAP SUMMARY:
==8445== in use at exit: 48,075,889 bytes in 14,975 blocks
==8445== total heap usage: 64,852 allocs, 49,877 frees, 107,416,930 bytes
allocated
==8445==
==8445== LEAK SUMMARY:
==8445== definitely lost: 0 bytes in 0 blocks
==8445== indirectly lost: 0 bytes in 0 blocks
==8445== possibly lost: 0 bytes in 0 blocks
==8445== still reachable: 48,075,889 bytes in 14,975 blocks
==8445== suppressed: 0 bytes in 0 blocks
==8445== Rerun with --leak-check=full to see details of leaked memory
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Aug 11, 2016 at 4:28 AM, Rajen Shah <rd...@cam.ac.uk> wrote:
> Hello,
>
> I am having trouble debugging a package that appears to work fine on Mac
> operating systems but crashes on Unix and Windows.
>
> I have found the following example that crashes on my Windows setup
> (session info copied below)
>
> IntegerVector runif_int2() {
> return wrap(floor(runif(1000000)));
> }
>
> When this is called about 5-10 times in succession R crashes (e.g. with
> set.seed(1), but this doesn't seem to matter).
>
> Any ideas about why this crashes would be much appreciated. To be clear, I
> am not looking for an alternative to the above code (which simply produces
> a vector of zeroes), but would like to know what aspects of this cause a
> crash so I know what code structures may be causing problems in the package
> I am creating. The code does not appear to crash on Mac and I have yet to
> try it on Unix.
>
> Many thanks in advance,
>
> Rajen
>
> Session info:
>
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows >= 8 x64 (build 9200)
>
> locale:
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
> States.1252 LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C LC_TIME=English_United
> States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_3.3.1
>
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
