segfault in get_extent of pillar-1.3.0 when using R-3.4.4

[kazumits]

I encountered a segfault caused by the recent changes in get_extent.
(crayon::strip_style was changed to fansi::strip_sgr in pillar 1.3.0)

The segfault was seen in R-3.4.4 on Linux (RHEL-7.3 and SLE-11 SP3).

The codes and the results are as follows.

> pillar::pillar_shaft(1:2)

 *** caught segfault ***
address 0x1, cause 'memory not mapped'

Traceback:
 1: .Call(FANSI_strip_csi, enc2utf8(x), strip.int, warn)
 2: fansi::strip_sgr(x, warn = FALSE)
 3: get_extent(x)
 4: get_max_extent(assemble_decimal(ret))
 5: set_width(ret, get_max_extent(assemble_decimal(ret)))
 6: split_decimal(x, sigfig, scientific = TRUE)
 7: format_scientific(x, ..., sigfig = sigfig)
 8: pillar_shaft.numeric(1:2)
 9: pillar::pillar_shaft(1:2)

(minimal version)

> fansi::strip_sgr(c("\033[m", "\033[m"))

 *** caught segfault ***
address 0x1, cause 'memory not mapped'

Traceback:
 1: .Call(FANSI_strip_csi, enc2utf8(x), strip.int, warn)
 2: fansi::strip_sgr(c("\033[m", "\033[m"))

This case may be related to R with intel ICC+MKL because
the miniconda version (built with gcc) did not reproduce the segfault.

Session info:

> sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux

Matrix products: default
BLAS/LAPACK: /usr/local/intel2018_up1/compilers_and_libraries_2018.0.128/linux/mkl/lib/intel64_lin/libmkl_in
tel_lp64.so

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

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

loaded via a namespace (and not attached):
[1] compiler_3.4.4

[krlmlr]

Thanks. @brodieG: Does this ring a bell?

[krlmlr]

(segfault in fansi::strip_sgr() on Intel ICC + MKL)

[brodieG]

No, but I will investigate. I'm certainly not intending on doing any fancy optimizations that would go differently under different compilers.

[brodieG]

I can't reproduce this right now, but I'll look at it more closely to see if there is anything that would trigger this.

[krlmlr]

Should be gone with the current CRAN version of fansi, thanks again @brodieG for looking into it! (Binaries for Windows and OS X aren't built yet, though.)

Please open a new issue if problems persist.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.