clang16-20 - testthat - unable to load shared object undefined symbol: __asan_register_elf_globals

[shail-choksi]

I am facing an issue that I don't understand with rhub:

  Error in `FUN()`:
  ! In path: "/__w/ToxicR/ToxicR/check/ToxicR.Rcheck/tests/testthat/helper.R"
  Caused by error:
  ! package or namespace load failed for 'actuar' in dyn.load(file, DLLpath = DLLpath, ...):
   unable to load shared object '/github/home/R/x86_64-pc-linux-gnu-library/4.5/expint/libs/expint.so':
    /github/home/R/x86_64-pc-linux-gnu-library/4.5/expint/libs/expint.so: undefined symbol: __asan_register_elf_globals
  Backtrace:
       ▆
    1. ├─testthat::test_check("ToxicR", dir = tempdir())
    2. │ └─testthat::test_dir(...)
    3. │   └─testthat:::test_files(...)
    4. │     └─testthat:::test_files_serial(...)
    5. │       └─testthat:::test_files_setup_state(...)
    6. │         └─testthat::source_test_helpers(".", env)
    7. │           └─testthat::source_dir(path, "^helper.*\\.[rR]$", env = env, wrap = FALSE)
    8. │             └─base::lapply(...)
    9. │               └─testthat (local) FUN(X[[i]], ...)
   10. │                 └─testthat::source_file(path, env = env, chdir = chdir, wrap = wrap)
   11. │                   ├─base::withCallingHandlers(...)
   12. │                   └─base::eval(exprs, env)
   13. │                     └─base::eval(exprs, env)
   14. │                       └─base::library(actuar) at tests/testthat/helper.R:1:1
   15. │                         └─base::tryCatch(...)
   16. │                           └─base (local) tryCatchList(expr, classes, parentenv, handlers)
   17. │                             └─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]])
   18. │                               └─value[[3L]](cond)
   19. │                                 └─base::stop(msg, call. = FALSE, domain = NA)
   20. └─base::.handleSimpleError(...)
   21.   └─testthat (local) h(simpleError(msg, call))
   22.     └─rlang::abort(...)
  Execution halted

Full logs here:
https://github.com/SciomeLLC/ToxicR/actions/runs/11802401294/job/32878139449

but the rhub pipeline passes for clang-asan. See the same link above.

Has anyone seen this before?

[gaborcsardi]

Seems like a bug, an incompatible binary package. I'll try to fix it soon.

[shail-choksi]

Thank you!

In the same runs there's also this:

https://github.com/SciomeLLC/ToxicR/actions/runs/11802401294/job/32878144042

Is that another bug? Should I make another issue for it?

[gaborcsardi]

I am sorry, I don't know what you are referring to. Which line(s) specifically?

[sciome-bot]

I am referring to:

* DONE (ToxicR)
objdump: Warning: Unrecognized form: 0x23
objdump: Warning: Unrecognized form: 0x23
objdump: Warning: Unrecognized form: 0x23
...
==== rchk bcheck =========================================
ERROR: too many states (abstraction error?) in function strptime_internal
ERROR: too many states (abstraction error?) in function bcEval_loop
ERROR: too many states (abstraction error?) in function StringValue
ERROR: too many states (abstraction error?) in function RunGenCollect

Function Rcpp::Armor<SEXPREC*>::init(SEXPREC*)
  [PB] has possible protection stack imbalance /github/home/R/x86_64-pc-linux-gnu-library/4.5/Rcpp/include/Rcpp/protection/Armor.h:47

Function Rcpp::Armor<SEXPREC*>::~Armor()
  [PB] has negative depth /github/home/R/x86_64-pc-linux-gnu-library/4.5/Rcpp/include/Rcpp/protection/Armor.h:41
  [UP] attempt to unprotect more items (1) than protected (0), results will be incomplete /github/home/R/x86_64-pc-linux-gnu-library/4.5/Rcpp/include/Rcpp/protection/Armor.h:41
  [PB] has possible protection stack imbalance /github/home/R/x86_64-pc-linux-gnu-library/4.5/Rcpp/include/Rcpp/protection/Armor.h:42

@gaborcsardi

[gaborcsardi]

No, that's not a bug in R-hub.

[gaborcsardi]

This is a bug in the cache key, the GHA cache is shared between the clang-asan and the other clang containers, but some packages built from source in clang-asan are not compatible with the other clang containers. A workaround for now is to clear the cache, this one:

Cache restored from key: Ubuntu 22.04.5 LTS-R version 4.5.0 (ge:16; iid:2fdf6c18-697a-4ba7-b8ef-11c0d92f1327)-ubuntu-22.04/4.5/libc++-eddfd8cb31dcb45997399a16d4083e1cb8b21bca1123f96cbbde4a020d483db4

https://github.com/SciomeLLC/ToxicR/actions/runs/11802401294/job/32878139449#step:5:5202

I'll have to think what to do with the cache key, so this does not happen.

[jameslamb]

I think we've just received a report in LightGBM that might have the same root cause:

microsoft/LightGBM#6836 (comment)

Using the clang-20 image from https://r-hub.github.io/containers/containers.html#clang20, someone reported seeing vignettes that library(lightgbm) and library(xgboost) failing like this:

Error: processing vignette 'classification_tasks.Rmd' failed with diagnostics:
unable to load shared object '/github/home/R/x86_64-pc-linux-gnu-library/4.5/lightgbm/libs/lightgbm.so':
/github/home/R/x86_64-pc-linux-gnu-library/4.5/lightgbm/libs/lightgbm.so: undefined symbol: __ubsan_vptr_type_cache
--- failed re-building ‘classification_tasks.Rmd’
--- re-building ‘regression_tasks.Rmd’ using rmarkdown
Quitting from lines 47-93 [unnamed-chunk-2] (regression_tasks.Rmd)
Error: processing vignette 'regression_tasks.Rmd' failed with diagnostics:
nable to load shared object '/github/home/R/x86_64-pc-linux-gnu-library/4.5/xgboost/libs/xgboost.so':

I don't see any compile lines in the logs they provided, so I strongly suspect it might be the same root cause... prebuilt packages from some other UBSAN build are getting picked up, and then failing to load because libubsan is not available.

{lightgbm} itself compiles successfully and passes R CMD check when built from source in the r-hub clang-20 images:

• [ci] [R-package] add CI job using clang-20 microsoft/LightGBM#6837
• https://github.com/microsoft/LightGBM/actions/runs/13426440812/job/37510171048?pr=6837#step:6:3817

[gaborcsardi]

@jameslamb Have you tried the workaround mentioned above?

[jameslamb]

I haven't, do you mean this?

A workaround for now is to clear the cache

My understanding of that comment is that that was something to be done by R-hub administrators. How do I do that myself?

[gaborcsardi]

I haven't, do you mean this?

A workaround for now is to clear the cache

My understanding of that comment is that that was something to be done by R-hub administrators. How do I do that myself?

See here: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#managing-caches

[jameslamb]

Sorry, I did not mean to make you search GitHub docs for me.

I just read https://github.com/r-hub/rhub?tab=readme-ov-file#setup ... I guess R-Hub has changed a lot since the last time I used it. The last time I used it, it was a managed service you submitted package tarballs to. It seems that now it's a client library that runs GitHub Actions workflows in your own (the package owner's) GitHub repositories.

I'll go try to reproduce this, following your advice. Thanks.

[jameslamb]

Confirmed that clearing the cache between runs did resolve this issue: microsoft/LightGBM#6836 (comment)