I want to thank Ivan and Bill for useful advice. I eventually found my memory
mistake,
which was of the 'obvious once you see it' variety. Ivan's note that it
appeared to be in
a small allocation was correct.
> I've hit a roadblock debugging a new update to the survival package. I do
> de
| >>> I often run R under valgrind with the command line:
| >>> $ R --quiet --no-save --debugger=valgrind
| >>> --debugger-args="--track-origins=yes --vgdb=full --vgdb-error=0"
| >>> then in another window start a debugger process with
| >>> $ gdb RHOME/bin/exec/R
| >>> ...
| >>>(gdb) tar
I haven't done any R memory debugging lately, but
https://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg10289.html
shows how I used to have gdb break where valgrind finds a problem so you
could examine the details.
Also, running your code after running gctorture(TRUE) can help tr
On Wed, 07 Feb 2024 14:01:44 -0600
"Therneau, Terry M., Ph.D. via R-devel" wrote:
> > test2 <- mysurv(fit2, pbc2$bili4, p0= 4:0/10, fit2, x0 =50)
> ==31730== Invalid read of size 8
> ==31730== at 0x298A07: Rf_allocVector3 (memory.c:2861)
> ==31730== by 0x299B2C: Rf_allocVector (Rinlinedf
I've hit a roadblock debugging a new update to the survival package. I do
debugging in
a developement envinment, i.e. I don't create and load a package but rather
source all
the .R files and dyn.load an .so file, which makes things a bit easier.
Running with R -d "valgrind --tool=memch
