Error : ‘length(cpuset) <= max_cores’ is not TRUE

[jeroen]

Some packages fail to build on WebAssembly with the following error:

Error : ‘length(cpuset) <= max_cores’ is not TRUE

It might have something to do with the shims that we use?

For example:

• https://github.com/r-universe/cran/actions/runs/26581650215/job/78317097632
• https://github.com/r-universe/cran/actions/runs/26581548838/job/78317325765
• https://github.com/r-universe/cran/actions/runs/26581216908/job/78315629523

[HenrikBengtsson]

Thanks for reporting. This looks it's triggered by a sanity check in the built-in parse for the "cpuset" value in CGroups v1 or v2. It could very well be a bug in the parse, e.g. a value format that is unaccounted for.

I might follow up later asking for help to rerun with a develop version were the error message gives more details on the value being parse.

[HenrikBengtsson]

It could also be in CGroups v2 (updated above comment). The CGroups v1 and v2 parsers are:

parallelly/R/cgroups.R

Lines 714 to 772 in 47d93f8

	getCGroups1CpuSet <- local({
	.cache <- NULL
	function() {
	res <- .cache
	if (!is.null(res)) return(res)
	## TEMPORARY: In case the cgroups options causes problems, make
	## it possible to override their values via hidden options
	cpuset <- get_package_option("cgroups.cpuset", NULL)
	if (!is.null(cpuset)) return(cpuset)
	## e.g. /sys/fs/cgroup/cpuset/cpuset.cpus
	value0 <- getCGroups1Value("cpuset", "cpuset.cpus")
	if (is.na(value0)) {
	res <- integer(0L)
	.cache <<- res
	return(res)
	}
	## Parse 0-63; 0-7,9; 0-7,10-12; etc.
	code <- gsub("-", ":", value0, fixed = TRUE)
	code <- sprintf("c(%s)", code)
	expr <- tryCatch({
	parse(text = code)
	}, error = function(ex) {
	warning(sprintf("Syntax error parsing %s: %s", sQuote(code), sQuote(value0)))
	integer(0L)
	})
	value <- tryCatch({
	suppressWarnings(as.integer(eval(expr)))
	}, error = function(ex) {
	warning(sprintf("Failed to parse %s: %s", sQuote(code), sQuote(value0)))
	integer(0L)
	})
	## Sanity checks
	max_cores <- maxCores()
	if (any(value < 0L | value >= max_cores)) {
	warning(sprintf("[INTERNAL]: Will ignore the cgroups CPU set, because it contains one or more CPU indices that is out of range [0,%d]: %s", max_cores - 1L, value0))
	value <- integer(0L)
	}
	if (any(duplicated(value))) {
	warning(sprintf("[INTERNAL]: Detected and dropped duplicated CPU indices in the cgroups CPU set: %s", value0))
	value <- unique(value)
	}
	cpuset <- value
	## Should never happen, but just in case
	stop_if_not(length(cpuset) <= max_cores)
	.cache <<- cpuset
	cpuset
	}
	})

parallelly/R/cgroups.R

Lines 884 to 944 in 47d93f8

	getCGroups2CpuSet <- local({
	.cache <- list()
	function(name = c("cpuset.cpus", "cpuset.cpus.effective")) {
	name <- match.arg(name)
	res <- .cache[[name]]
	if (!is.null(res)) return(res)
	## TEMPORARY: In case the cgroups options causes problems, make
	## it possible to override their values via hidden options
	cpuset <- get_package_option(paste0("cgroups2.", name), NULL)
	if (!is.null(cpuset)) return(cpuset)
	## e.g. /sys/fs/cgroup/cpuset.cpus or /sys/fs/cgroup/cpuset.cpus.effective
	value0 <- getCGroups2Value(name)
	if (is.na(value0)) {
	res <- integer(0L)
	.cache[[name]] <<- res
	return(res)
	}
	## Parse 0-63; 0-7,9; 0-7,10-12; etc.
	code <- gsub("-", ":", value0, fixed = TRUE)
	code <- sprintf("c(%s)", code)
	expr <- tryCatch({
	parse(text = code)
	}, error = function(ex) {
	warning(sprintf("Syntax error parsing cgroups v2 %s: %s", sQuote(name), sQuote(value0)))
	integer(0L)
	})
	value <- tryCatch({
	suppressWarnings(as.integer(eval(expr)))
	}, error = function(ex) {
	warning(sprintf("Failed to parse cgroups v2 %s: %s", sQuote(name), sQuote(value0)))
	integer(0L)
	})
	## Sanity checks
	max_cores <- maxCores()
	if (any(value < 0L | value >= max_cores)) {
	warning(sprintf("[INTERNAL]: Will ignore the cgroups v2 CPU set, because it contains one or more CPU indices that is out of range [0,%d]: %s", max_cores - 1L, value0))
	value <- integer(0L)
	}
	if (any(duplicated(value))) {
	warning(sprintf("[INTERNAL]: Detected and dropped duplicated CPU indices in the cgroups v2 CPU set: %s", value0))
	value <- unique(value)
	}
	cpuset <- value
	## Should never happen, but just in case
	stop_if_not(length(cpuset) <= max_cores)
	.cache[[name]] <<- cpuset
	cpuset
	}
	})

[jeroen]

I found it is related to these shims: https://github.com/r-wasm/rwasm/blob/main/inst/webr-profile

[jeroen]

Is it normal that people run this code at package build time?

https://github.com/cran/QBMS/blob/9183e3d852fb75156b8f487c80e0dac3c898def6/R/http.R#L2C1-L2C35

[jeroen]

Here is a reproducible example:

base_version <- R.Version()
base_version$os <- "emscripten"

shim_R.version <- base_version
shim_R.Version <- function() { base_version }

utils::assignInNamespace("R.version", shim_R.version, ns = "base")
utils::assignInNamespace("R.Version", shim_R.Version, ns = "base")

future::plan(future::multisession)

[HenrikBengtsson]

I found it is related to these shims: https://github.com/r-wasm/rwasm/blob/main/inst/webr-profile

Interesting - it's not obvious to me how that could possibly affect it, but maybe those shims allowed parallelly::availableCores() go down a separate code path. Hopefully a useful clue.

Are these shims deployed anywhere for me to run manual checks, e.g. are they on https://webr.sh/?

Is it normal that people run this code at package build time?

Exactly my thought too. I can see how some my query parallelly::availableCores() on package load, but ...

https://github.com/cran/QBMS/blob/9183e3d852fb75156b8f487c80e0dac3c898def6/R/http.R#L2C1-L2C35

... yeah, that one is either a leftover cut'n'paste mistake, or a misunderstanding - that should not be done, and especially not there. (I love how a potential bug on my end may end up catching bugs elsewhere)

[HenrikBengtsson]

Here is a reproducible example:

Thanks. I can reproduce in regular R 4.6.0 on Ubuntu.

[HenrikBengtsson]

A smaller reproducible example was:

base_version <- R.Version()
base_version$os <- "emscripten"

shim_R.version <- base_version
shim_R.Version <- function() { base_version }

utils::assignInNamespace("R.version", shim_R.version, ns = "base")
utils::assignInNamespace("R.Version", shim_R.Version, ns = "base")

parallelly::availableCores(methods = "cgroups2.cpuset.cpus")  # ERROR

That one was interesting, because although /sys/fs/cgroup/user.slice/cpuset.cpus has zero size;

$ ls -l /sys/fs/cgroup/user.slice/cpuset.cpus
-rw-r--r-- 1 root root 0 May 31 18:29 /sys/fs/cgroup/user.slice/cpuset.cpus

$ stat /sys/fs/cgroup/user.slice/cpuset.cpus
  File: /sys/fs/cgroup/user.slice/cpuset.cpus
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,30	Inode: 415         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-05-31 18:29:31.010890233 -0700
Modify: 2026-05-31 18:29:31.010890233 -0700
Change: 2026-05-31 18:29:31.010890233 -0700
 Birth: -

it comprise of one character (LF) if read;

$ wc /sys/fs/cgroup/user.slice/cpuset.cpus
1 0 1 /sys/fs/cgroup/user.slice/cpuset.cpus

$ cat -A /sys/fs/cgroup/user.slice/cpuset.cpus
$

$ bat -p -A /sys/fs/cgroup/user.slice/cpuset.cpus
␊

This led to readLines(..., warn = FALSE) returning "" instead of character(0L). TIL (kind of)

I've fixed this in the develop branch.

While at it, I also discovered that:

parallelly::availableCores(methods = "cgroups2.cpuset.cpus.effective") # ERROR

would produce Error in if (any(value < 0L | value >= max_cores)), simplify because parallel::detectCores() returned NA_integer_ (one of my favorite examples, and I fell for it myself).

@jeroen can you please check this fix against what you're running?

[HenrikBengtsson]

Re file size zero: Oh, it's because /sys/ is a virtual file system mounting dynamically generated content, i.e. file size is zero for bc content is unknown. I think I knew this, but forgot. Plus, Unix is polite enough to make sure all lines end with a newline. Oh well...