| >>> 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
I put the idea below into a function that gives nicer looking results.
Here's the new code:
dupnames <- function(path = ".") {
Rfiles <- pkgload:::find_code(path)
allnames <- data.frame(names=character(), filename=character(), line
= numeric())
result <- NULL
for (f in Rfiles) {
e
On 07/02/2024 8:36 a.m., luke-tier...@uiowa.edu wrote:
On Tue, 6 Feb 2024, Duncan Murdoch wrote:
The SO post https://stackoverflow.com/q/77943180 tried to call
globalCallingHandlers() from a function, and it failed with the error message
"should not be called with handlers on the stack". A muc
I agree a note about this sort of change might be good.
I think it wouldn't be too hard to write such a check to detect simple
assignments using <- or =. If you also wanted to detect method
redefinitions, or redefinitions of functions stored in lists, etc., it
would be harder.
There's unexp
On Tue, 6 Feb 2024, Duncan Murdoch wrote:
The SO post https://stackoverflow.com/q/77943180 tried to call
globalCallingHandlers() from a function, and it failed with the error message
"should not be called with handlers on the stack". A much simpler
illustration of the same error comes from th
Hopefully to too much of a tangent: A related problem this check doesn’t catch
is accidental top-level redefinitions in package code, such as
## a.R:
helper <- function() 1
f <- function() {
helper()
}
# “cool, f() must return 1"
## b.R:
helper <- function(x) 2
g <- function() {
helper()
}
# “
This is my first time working with dates, so if the answer is "Duh, work
with POSIXt", please ignore it.
Why is not `round.Date` and `trunc.Date` "implemented" for `Date`?
Is this because `Date` is (mostly) a virtual class setup for a better
inheritance or is that something that is just missin
10 matches
Mail list logo
