Invalid multibyte string

[const-ae]

Hi,

I am running some code on our cluster and keep hitting an error about an invalid multibyte string when a function is called with a future. The following reproduces the error in a fresh session on the cluster:

Sys.setlocale('LC_ALL',"en_GB.UTF-8")
future::future(expression(1 + 1))

> Error in substring(x, m + 1L) : invalid multibyte string at '<ff>-i'
> In addition: Warning message:
> In regexpr("=", x, fixed = TRUE) :
>   input string 74 is invalid in this locale

If I set the locale to "C" the error disappears:

Sys.setlocale('LC_ALL',"C")
future::future(expression(1 + 1))

SessionInfo:

> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /share/apps/R-4.4.1/lib64/R/lib/libRblas.so
LAPACK: /share/apps/R-4.4.1/lib64/R/lib/libRlapack.so;  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8
 [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/London
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.4.1    parallelly_1.38.0 tools_4.4.1       parallel_4.4.1
[5] listenv_0.9.1     codetools_0.2-20  digest_0.6.37     globals_0.16.3
[9] future_1.34.0

The error does not appear when I run the code with the en_GB.UTF-8 locale on my MacBook, so I am at a bit of a loss on how to debug this.

The obvious fix to just always set Sys.setlocale('LC_ALL',"C") at the beginning of the script works most of the time, but sometimes the code seems to forget about the setting and still crashes.

[HenrikBengtsson]

Thanks for reporting. After some searching, it looks like regexpr("=", x, fixed = TRUE) and substring(x, m + 1L) are from base::Sys.getenv() at https://github.com/r-devel/r-svn/blob/3713345283787c928e563cdcdf01cc4a9dc1c708/src/library/base/R/getenv.R#L25-L26. Given this, do you also get the error on this system when using:

Sys.setlocale("LC_ALL", "en_GB.UTF-8")
envs <- Sys.getenv()

?

[saeed6944]

Hi,

I am running some code on our cluster and keep hitting an error about an invalid multibyte string when a function is called with a future. The following reproduces the error in a fresh session on the cluster:

Sys.setlocale('LC_ALL',"en_GB.UTF-8")
future::future(expression(1 + 1))

> Error in substring(x, m + 1L) : invalid multibyte string at '<ff>-i'
> In addition: Warning message:
> In regexpr("=", x, fixed = TRUE) :
>   input string 74 is invalid in this locale

If I set the locale to "C" the error disappears:

Sys.setlocale('LC_ALL',"C")
future::future(expression(1 + 1))

SessionInfo:

> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /share/apps/R-4.4.1/lib64/R/lib/libRblas.so
LAPACK: /share/apps/R-4.4.1/lib64/R/lib/libRlapack.so;  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8
 [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/London
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.4.1    parallelly_1.38.0 tools_4.4.1       parallel_4.4.1
[5] listenv_0.9.1     codetools_0.2-20  digest_0.6.37     globals_0.16.3
[9] future_1.34.0

The error does not appear when I run the code with the en_GB.UTF-8 locale on my MacBook, so I am at a bit of a loss on how to debug this.

The obvious fix to just always set Sys.setlocale('LC_ALL',"C") at the beginning of the script works most of the time, but sometimes the code seems to forget about the setting and still crashes.