Segmentation fault

Interfaces brms
1

Hi, I am running brms on a linux cluster. Randomly, during a for loop in which models are fitted I get the following segmentation fault error:

*** caught segfault ***
address 0x7fd57fa66528, cause ‘memory not mapped’

Traceback:
1: .Call(list(name = “CppObject__finalize”, address = <pointer: 0x407a0a0>, dll = list(name = “Rcpp”, path = “…/R/x86_64-pc-linux-gnu-library/3.6/Rcpp/libs/Rcpp.so”, dynamicLookup = TRUE, handle = <pointer: 0x39e09e0>, info = <pointer: 0x191dfe0>), numParameters = 2L), <pointer: 0x1937bd120>, .pointer)
2: x$.self$finalize()
3: (function (x) x$.self$finalize())()

Do you have any suggestion?
This is my session info:

R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS: …/R-3.6.1/lib/libRblas.so
LAPACK: …/R-3.6.1/lib/libRlapack.so

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

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

other attached packages:
[1] brms_2.9.0 Rcpp_1.0.1 rstan_2.19.2
[4] ggplot2_3.2.0 StanHeaders_2.18.1-10

loaded via a namespace (and not attached):
[1] mvtnorm_1.0-11 lattice_0.20-38 gtools_3.8.1
[4] prettyunits_1.0.2 ps_1.3.0 zoo_1.8-6
[7] assertthat_0.2.1 digest_0.6.20 mime_0.7
[10] R6_2.4.0 plyr_1.8.4 backports_1.1.4
[13] ggridges_0.5.1 stats4_3.6.1 coda_0.19-3
[16] colourpicker_1.0 pillar_1.4.2 rlang_0.4.0
[19] lazyeval_0.2.2 miniUI_0.1.1.1 callr_3.3.0
[22] DT_0.7 Matrix_1.2-17 shinythemes_1.1.2
[25] shinyjs_1.0 stringr_1.4.0 htmlwidgets_1.3
[28] loo_2.1.0 igraph_1.2.4.1 munsell_0.5.0
[31] shiny_1.3.2 compiler_3.6.1 httpuv_1.5.1
[34] pkgconfig_2.0.2 base64enc_0.1-3 pkgbuild_1.0.3
[37] rstantools_1.5.1 htmltools_0.3.6 tidyselect_0.2.5
[40] tibble_2.1.3 gridExtra_2.3 threejs_0.3.1
[43] matrixStats_0.54.0 crayon_1.3.4 dplyr_0.8.3
[46] withr_2.1.2 later_0.8.0 grid_3.6.1
[49] nlme_3.1-140 xtable_1.8-4 gtable_0.3.0
[52] magrittr_1.5 scales_1.0.0 cli_1.1.0
[55] stringi_1.4.3 reshape2_1.4.3 promises_1.0.1
[58] xts_0.11-2 dygraphs_1.1.1.6 tools_3.6.1
[61] glue_1.3.1 markdown_1.0 shinystan_2.5.0
[64] purrr_0.3.2 crosstalk_1.0.0 rsconnect_0.8.13
[67] processx_3.4.0 abind_1.4-5 parallel_3.6.1
[70] inline_0.3.15 colorspace_1.4-1 bridgesampling_0.6-0
[73] bayesplot_1.7.0 Brobdingnag_1.2-6

2

I think we are aware of this (aren’t we @bgoodri?) but I am not sure if we have a fix for this sporadically occuring problem yet…

3

No real fix other than slowing the loop down with Sys.sleep calls.

4

Hi thanks a lot for your fast reply.
How i should implement the Sys.sleep solution? Is this the correct way?

for(i in 1:10){ fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data = epilepsy, family = poisson()) Sys.sleep(i) }

5

Sys.sleep takes a number of seconds so just play around with it. But you should also be able to use the update method for a brmsfit object to avoid reloading the dynamic shared object.

6

Thanks a lot, I am using 10 seconds for now. I do no think i can use update because i am changing not only dataset but also the formula in the loop, am I correct?

giuseppe

7

If you are changing the formula you may still use update (in most cases), but it may trigger a recompilation if changing the formula implies a change in the stan code.

8

Dear Paul, thanks a lot.
Using other explanatory variables in the formula seems that update re-compile again.
For the segfault error, 10 seconds did not work. I increased the sleep time to 20 and see what happens.

Do you think that if I downgrade stan, stanheaders, bh, and brms is possible to avoid this segfault error?

best regards

9

You could try to run these models in parallel and depending on the implementation it will open new R processes, which, in my experience, prevent these segfaults from happening (as models are compiled in different sessions). You could for instance use the foreach package in combination with doParallel.

10

Dear Paul, using both foreach/doParallel and Sys.sleep solved the problem for me.
Thanks a lot