Re: [R-pkg-devel] How to debug segfault when running build -> document in Rstudio that includes TMB module
Carl,
Consider performing these tasks without the use of the 'devtools' package,
running the following from a shell.
```shell
R CMD build .
R CMD INSTALL --with-keep.source ./SPAS_*.tar.gz
# (assuming you use roxygen2)
Rscript -e "roxygen2::roxygenize(load = 'installed')"
R CMD check --as-cran ./SPAS_*.tar.gz
```
If those commands are successful, then you know the problem lies somewhere
in the difference between that approach and what 'devtools' does, which
might help to narrow it down.
Cheers,
-James
On Tue, Jan 23, 2024 at 9:23 PM Carl Schwarz
wrote:
> I'm trying to update my SPAS package to respond to a CRAN check. Before
> starting the changes, I tried to rebuild my package, but now get a segfault
> when I try to do a devtools::document() or devtools::check(args =
> c('--as-cran')). See below for output from the Rstudio "Build" window.
>
> I've
> - reinstalled ALL packages
> - reinstalled R (4.3.2 on MacOS Intel Chip)
> - reinstalled Rstudio
>
> When I try a rebuild/document on a sister package it runs fine, so I
> suspect that the problem is related to using a TMB module that is part of
> the SPAS package written in Cpp.
>
> How do I start to "debug" this to identify the problem?
>
> Thanks
> Carl Schwarz
>
>
>
>
> ==> devtools::document(roclets = c('rd', 'collate', 'namespace',
> 'vignette'))
> ℹ Updating SPAS documentationℹ Loading SPAS
>
> *** caught segfault ***
> address 0x54e40, cause 'memory not mapped'
>
> Traceback:
> 1: dyn.load(dll_copy_file)
> 2: library.dynam2(path, lib)
> 3: load_dll(path)
> 4: pkgload::load_all(path, helpers = FALSE, attach_testthat = FALSE)
> 5: load_code(base_path)
> 6: roxygen2::roxygenise(pkg$path, roclets)
> 7: devtools::document(roclets = c("rd", "collate", "namespace",
> "vignette"))
> 8: withCallingHandlers(expr, packageStartupMessage = function(c)
> tryInvokeRestart("muffleMessage"))
> 9: suppressPackageStartupMessages({oldLC <-
> Sys.getlocale(category = "LC_COLLATE")Sys.setlocale(category =
> "LC_COLLATE", locale = "C")on.exit(Sys.setlocale(category =
> "LC_COLLATE", locale = oldLC))devtools::document(roclets = c("rd",
> "collate", "namespace", "vignette"))})
> An irrecoverable exception occurred. R is aborting now ...
>
> Exited with status 139.
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
James Lamb (he/him)
GitHub <https://github.com/jameslamb> | LinkedIn
<https://www.linkedin.com/in/jameslamb1/>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Tracking down cause of UBSAN error
To add to Dirk's summary of the available options, you might find it useful
to borrow from the setup that we use to replicate CRAN's UBSAN checks on
GitHub Actions for {lightgbm}.
https://github.com/microsoft/LightGBM/blob/0c1c36cdbdf771a03c9ae0873eb28585e6c3d624/.github/workflows/r_package.yml#L162-L186
I was able to reproduce all of the specific issues in {lightgbm} that
showed up on CRAN's UBSAN checks with this setup, which uses the
rhub/rocker-gcc-san image. It should be easy enough to switch that to the
images from https://github.com/wch/r-debug if necessary.
Hope that it helps!
-James
On Thu, Oct 15, 2020 at 9:08 PM Dirk Eddelbuettel wrote:
>
> Hugh,
>
> The different SAN/ASAB/UBSAN/... analysers depend critically on _exactly
> how_
> the instrumentation is setup. That make the whole setup analysis a little
> brittle, and it is a real shame that neither CRAN nor some of the entities
> supposedly here in order to support R users and developers have managed to
> produced _standardized_ environments (using, say, Docker) to make this
> genuinely reproducible. So we all waste time chasing things over and over.
>
> Five or so years ago I wrote a first container for this; I believe the RHub
> one is a descendant of it. But I found reproducing errors so tricky that I
> set up an entire package just to provide 'true positives' for such tests of
> the testing framework: http://cloud.r-project.org/package=sanitizers
> It helps validate that the setup (container, say) catches what it is
> supposed
> to catch--as this is (too) easy to get wrong.
>
> These days I think the contains within the (very well done and complete)
> "collection" of containers maintained by Winston might be your best bet:
> https://github.com/wch/r-debug
> This is what I used last time I needed something like it.
>
> Hth, Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
James Lamb
GitHub <https://github.com/jameslamb> | Twitter
<https://twitter.com/_jameslamb> | LinkedIn
<https://www.linkedin.com/in/jameslamb1/>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is there an Rtools40 changelog?
Thank you very much for the help!
This definitely answered my question. I wasn't familiar with pacman before.
For the curious, I've had success generating a .def file from R.dll with
*objdump.exe*, a utility that exists in prior Rtools distributions and
the current ones. With something like the R code below.
```r
# [description]
# Create a definition file (.def) from a .dll file, using objdump.
#
# [usage]
#
# Rscript make-r-def.R something.dll something.def
#
# [references]
#* https://www.cs.colorado.edu/~main/cs1300/doc/mingwfaq.html
args <- commandArgs(trailingOnly = TRUE)
IN_DLL_FILE <- args[[1L]]
OUT_DEF_FILE <- args[[2L]]
DLL_BASE_NAME <- basename(IN_DLL_FILE)
print(sprintf("Creating '%s' from '%s'", OUT_DEF_FILE, IN_DLL_FILE))
# use objdump to dump all the symbols
OBJDUMP_FILE <- "objdump-out.txt"
exit_code <- system2(
command = "objdump"
, args = c(
"-p"
, shQuote(IN_DLL_FILE)
)
, stdout = OBJDUMP_FILE
)
objdump_results <- readLines(OBJDUMP_FILE)
result <- file.remove(OBJDUMP_FILE)
# Only one table in the objdump results matters for our purposes,
# see https://www.cs.colorado.edu/~main/cs1300/doc/mingwfaq.html
start_index <- which(
grepl(
pattern = "[Ordinal/Name Pointer] Table"
, x = objdump_results
, fixed = TRUE
)
)
empty_lines <- which(objdump_results == "")
end_of_table <- empty_lines[empty_lines > start_index][1L]
# Read the contents of the table
exported_symbols <- objdump_results[(start_index + 1L):end_of_table]
exported_symbols <- gsub("\t", "", exported_symbols)
exported_symbols <- gsub(".*\\] ", "", exported_symbols)
exported_symbols <- gsub(" ", "", exported_symbols)
# Write R.def file
writeLines(
text = c(
paste0("LIBRARY \"", DLL_BASE_NAME, "\"")
, "EXPORTS"
, exported_symbols
)
, con = OUT_DEF_FILE
, sep = "\n"
)
```
On Tue, May 12, 2020 at 2:39 AM Jeroen Ooms wrote:
> On Sun, May 10, 2020 at 11:31 PM James Lamb wrote:
> >
> > Hello,
> >
> > I am a maintainer on the LightGBM project, focused on that project's R
> > package. The R package is not available on CRAN yet (we are working on
> it),
> > so for now our users must build it from source.
> >
> > The package includes compilation of a C++ library, and we link to R.dll /
> > R.so to use R-provided functions like Rprintf.
> >
> > With the release of R4.0 and Rtools40, we recently received reports from
> > our users that they are unable to build our package on Windows systems
> with
> > R 4.0 and Rtools 4.0 (https://github.com/microsoft/LightGBM/issues/3064
> ).
> >
> > After some investigation, I've learned that the following changes in
> > Rtools40 (relative to Rtools35) broke our installation process:
> >
> >- *gendef.exe* was removed
> >- *mingw32-make.exe* was removed
> >- paths like "mingw_64/bin" were changed to "mingw64/bin"
> >
>
> Some utilities that were previously bundled with all rtools
> installations can now be installed with the package manager.
>
> To install gendef use:
>
> pacman -S mingw-w64-{i686,x86_64}-tools
>
> To install mingw32-make.exe use:
>
> pacman -S mingw-w64-{i686,x86_64}-make
>
> To install both of the at once you can use:
>
> pacman -S mingw-w64-{i686,x86_64}-{tools,make}
>
> Note that it's often better to use 'make.exe' which is included with
> all rtools installations instead of mingw32-make.exe.
>
> These changes were a result of switching to an msys2 based toolchain.
> The default rtools40 installer only includes the things needed to
> build CRAN packages or base-R. Extra stuff such as system libraries,
> debuggers, cmake, etc, are all optionally available via the package
> manager.
>
--
James Lamb
GitHub <https://github.com/jameslamb> | Twitter
<https://twitter.com/_jameslamb> | LinkedIn
<https://www.linkedin.com/in/jameslamb1/>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Is there an Rtools40 changelog?
Hello, I am a maintainer on the LightGBM project, focused on that project's R package. The R package is not available on CRAN yet (we are working on it), so for now our users must build it from source. The package includes compilation of a C++ library, and we link to R.dll / R.so to use R-provided functions like Rprintf. With the release of R4.0 and Rtools40, we recently received reports from our users that they are unable to build our package on Windows systems with R 4.0 and Rtools 4.0 (https://github.com/microsoft/LightGBM/issues/3064). After some investigation, I've learned that the following changes in Rtools40 (relative to Rtools35) broke our installation process: - *gendef.exe* was removed - *mingw32-make.exe* was removed - paths like "mingw_64/bin" were changed to "mingw64/bin" I do not expect that our off-CRAN installation process is supported. I understand that by maintaining our own process, we are taking on the burden of keeping up with new releases of R and Rtools. My question is this...is there public documentation about why the changes I mentioned above were made? I have not found any mention of them in the following places, and am not sure where else to look. - https://cran.r-project.org/bin/windows/Rtools/ - https://github.com/r-windows/docs/blob/master/faq.md#readme - https://jeroen.github.io/rstudio2019 Thank you very much for your time and consideration, -James Lamb [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
