Thanks, Ivan, for looking into this and providing some reassurance. Gabor 
suggested and that worked like a charm. A check 
there on the Intel platform found no errors in my present version of 
secrdesign, so I'll resubmit with confidence. The original error remains a 
mystery, but not one I need to pursue.

From: Ivan Krylov <>
Sent: Friday, 1 March 2024 21:46
To: Murray Efford <>
Cc: <>
Subject: Re: [R-pkg-devel] Additional issues: Intel segfault

В Fri, 1 Mar 2024 07:42:01 +0000
Murray Efford <> пишет:

> R CMD check suggests it is most likely in the Examples for
> 'validate', but all code there is wrapped in \dontrun{}.

The crash happens after q('no'), suggesting a corruption in the heap or
in the R memory manager. At least it's a null pointer being
dereferenced and not a 0xRANDOM_LOOKING_NUMBER: this limits the impact
of the problem.

I don't know if anyone created an easily reproducible container with an
Intel build of R (there's, but
aren't the compilers themselves supposed to be not redistributable?),
so you will most likely have to follow and
manually, compiling R using Intel compilers yourself in order to
reproduce this.

I think it would be great if CRAN checking machines used a just-in-time
debugger to provide C-level backtraces at the place of the crash. For
Windows, such a utility does exist [*], but I recently learned that the
glibc `catchsegv` program (and most other similar programs) used to
perform shared object preloading (before being thrown out of the
codebase altogether), which is more intrusive than it could be. A proof
of concept using GDB on Linux can be shown to work:

R -d gdb \
 --debugger-args='-batch -ex run -ex bt -ex c -ex q' \
 -e '
  Rcpp::sourceCpp(code =
   "//[[Rcpp::export]]\nvoid rip() { *(double*)(42) = 42; }"
  ); rip()

Best regards,


______________________________________________ mailing list

Reply via email to