Check logs from cheking CRAN packages on the M1mac system detailed
at https://www.stats.ox.ac.uk/pub/bdr/M1mac/README.txt .

R and packages were compiled with ASAN + UBSAN (see
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Checking-memory-access
)

using config.site containing

CC="clang -mmacos-version-min=26 -fsanitize=address,undefined"
CXX="clang++ -mmacos-version-min=26 -fsanitize=address,undefined"
REC_INSTALL_OPT=--dsym

and checked with environment variables

setenv MallocNanoZone 0
setenv UBSAN_OPTIONS 'print_stacktrace=1'


Per-package notes
-----------------

Also Linux: 

Alignment: RcppHNSW
  (Those which are 0x000000000001 are likely attempts to access an element
  of a 0-lemgth R vector.  Note that on macOS calling memcpy etc with
  a zero size does access the 'src' pointer.  Some people claim 
  (https://en.cppreference.com/cpp/string/byte/memcpy) 'src' must be a
  non-NULL and valid pointer, but the C, C++ and POSIX standards do not seem to.

Archived: CovRegRF LTRCforests MRS RFpredInterval SlaPMEG apLCMS
  bayestransmission fanc fastQR ichimoku spRFA

(reported) 
(and ignored) pander rswipl(repeatedly) terra(repeatedly)

gtools, restfulr (when rsolr is installable): in system socket headers.
stringi: in system ICU
tesseract: in downloaded compiled code, so probably a false positive
  (but downloading compiled code is a CRAN policy violation).