Data.table: Mudança de desenvolvimento R; R-API dentro de regiões paralelas

Criado em 30 nov. 2018 · 4Comentários · Fonte: Rdatatable/data.table

Luke Tierney entrou em contato comigo sobre um problema de memória no R-devel. Os testes estão passando no CRAN e no Travis / Appveyor, mas o uso de memória é maior em alguns casos. Como antes, o coletor de lixo é desligado.
Não tenho certeza de quando exatamente a alteração R-devel foi feita, mas em algum momento no último mês ou assim. Pode ser que a alteração do R-devel cause o novo problema de memória ou que a alteração do R-devel revele o problema que já existe (possivelmente até com data.table-release no R-release). Em qualquer caso, ele precisa ser consertado.

Lucas escreveu:

I distilled the issue in 'constellation' down to the attached file
from the examples. If I run this the memory usage is much bigger than
previously and the gc() output is garbled. It's a
multi-threading issue again; everything looks fine with
OMP_NUM_THREADS=1. With mutlipe threads you are
calling DATAPTR from threads other than the main one and that creates
a race on setting the R_GCEnabled flag, so eventually it is getting
stuck on off. I instrumented the places where the GC is disabled and
tracked this as the first one from a thread other than the main one:

#4  0x00007ffff78ba9d5 in DATAPTR (x=x@entry=0x1167458)
     at ../../../R/src/include/Rinlinedfuns.h:106
#5  0x00007fffea02c4c8 in subsetVectorRaw (target=0x4529590, source=0x1167458,
     idx=0x4175210, any0orNA=FALSE) at subset.c:44
#6  0x00007fffea02c7a6 in subsetDT (x=<optimized out>, rows=<optimized out>,
     cols=<optimized out>) at subset.c:272

Dados os detalhes de Luke, é fácil ver o problema no código sem precisar reproduzi-lo. Todo o uso da API R precisa ser levado fora de todas as regiões paralelas, conforme Luke solicitou antes. Demorei a fazer isso da última vez devido à pressão do tempo e agora precisa ser resolvido. Da última vez, acabei de fazer a primeira etapa que era garantir que DATAPTR dentro de regiões paralelas não recebesse ALTREP.

Isso garante o lançamento acelerado de 1.12.0, não menos porque impacta Luke.

$ grep "omp.*parallel" *.c

[x] subconjunto.c
[x] reordenar.c
[x] fwrite.c
[x] fread.c
[x] fsort.c
[x] forder.c
[x] entre c

$ grep ALTREP *.c

[x] entre c
[x] fsort.c
[x] reordenar.c
[x] wrappers.c

R-devel bug

Fonte

mattdowle

❤3

Comentários muito úteis

incrível de Luke fazer todo o trabalho árduo de identificar a causa! 💯

MichaelChirico em 30 nov. 2018

👍5

Todos 4 comentários

incrível de Luke fazer todo o trabalho árduo de identificar a causa! 💯

MichaelChirico em 30 nov. 2018

👍5

Estou em processo de confirmação com Luke que está consertado antes de fechar ...

mattdowle em 7 dez. 2018

Confirmado corrigido. Obrigado a @ltierney por sua ajuda.

Para integridade, caso seja necessário voltar a consultar ...
Não consegui reproduzir o problema com o R-devel compilado da seguinte forma. (Eu precisava confirmar que podia reproduzir o problema com 1.11.8 antes de poder confirmar que o 1.11.9 o corrige.)

./configure --without-recommended-packages --disable-byte-compiled-packages --enable-strict-barrier CC="gcc -fsanitize=address -fno-sanitize=float-divide-by-zero -fno-omit-frame-pointer" CFLAGS="-O0 -g -Wall -pedantic"

mesmo com o script que Lucas forneceu:

library(data.table)
library(constellation)
temp <- as.data.table(vitals[VARIABLE == "TEMPERATURE"])
pulse <- as.data.table(vitals[VARIABLE == "PULSE"])
resp <- as.data.table(vitals[VARIABLE == "RESPIRATORY_RATE"])
temp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
pulse[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
resp[, RECORDED_TIME := as.POSIXct(RECORDED_TIME,
  format = "%Y-%m-%dT%H:%M:%SZ", tz = "UTC")]
gc()
for (i in 1:10) {
  cat("i=",i,"\n")
  b1 <- bundle(temp, pulse, resp,
    bundle_names = c("PLATELETS", "INR"), window_hours_pre = 24,
    window_hours_post = c(6, 6), join_key = "PAT_ID",
    time_var = "RECORDED_TIME", event_name = "CREATININE", mult = "all")
}
gc()

Em uma hipótese remota, recompilei R-devel mais simplesmente da seguinte maneira, ainda com --enable-strict-barrier que é o mais importante:
./configure --without-recommended-packages --enable-strict-barrier
constelação reinstalada e todas as suas dependências e data.table 1.11.8, e desta vez o script de Lucas falha corretamente:

Fatal error: Wrong thread calling 'RunFinalizers'

Instalar data.table-dev (1.11.9) neste R-devel e rodar novamente funciona bem. Reinstalar data.table 1.11.8 novamente falha. Portanto, está de fato corrigido por 1.11.9. Na minha compilação R-devel original, talvez algo lá estivesse fazendo o 1.11.8 funcionar (desativando o compilador de bytes, -00, ASAN, etc). De qualquer forma, uma compilação R-devel mais simples era necessária e valia a pena tentar.

@jangorecki Se o tempo permitir, seria ótimo adicionar --enable-strict-barrier ao R-devel usado em pipelines de CI. Não sei se você compila o R-devel ou não para pipelines de CI.

mattdowle em 10 dez. 2018

@mattdowle sim eu compilo R-devel diariamente, irei adicionar esta flag lá. Adicionado para não esquecer em # 3147