Data.table: Changement de R-devel; R-API dans les régions parallèles

Créé le 30 nov. 2018 · 4Commentaires · Source: Rdatatable/data.table

Luke Tierney m'a contacté à propos d'un problème de mémoire dans R-devel. Les tests passent à la fois sur CRAN et Travis / Appveyor, mais l'utilisation de la mémoire est plus élevée dans certains cas. Comme auparavant, le garbage collector s'éteint.
Je ne sais pas quand exactement le changement de R-devel a été effectué, mais quelque temps au cours du dernier mois environ. Il se peut que le changement de R-devel provoque le nouveau problème de mémoire, ou que le changement de R-devel révèle le problème qui existe déjà (peut-être même avec data.table-release sur R-release). Dans tous les cas, il faut le réparer.

Luke a écrit:

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

Compte tenu des détails de Luke, il est facile de voir le problème dans le code sans avoir besoin de le reproduire. Toutes les utilisations de l'API R doivent sortir de toutes les régions parallèles, comme Luke l'a demandé auparavant. J'ai retardé le faire la dernière fois en raison de la pression du temps, et maintenant il faut s'attaquer. La dernière fois, j'ai juste fait la première étape qui était de m'assurer que DATAPTR à l'intérieur des régions parallèles ne recevait pas ALTREP.

Cela justifie une sortie accélérée de la 1.12.0, notamment parce qu'elle a un impact sur Luke.

$ grep "omp.*parallel" *.c

[x] sous-ensemble.c
[x] réorganiser.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] réorganiser.c
[x] wrappers.c

R-devel bug

Source

mattdowle

❤3

Commentaire le plus utile

génial de Luke pour faire tout le travail acharné pour identifier la cause! 💯

MichaelChirico le 30 nov. 2018

👍5

Tous les 4 commentaires

génial de Luke pour faire tout le travail acharné pour identifier la cause! 💯

MichaelChirico le 30 nov. 2018

👍5

Je suis en train de confirmer avec Luke que c'est corrigé avant de fermer ...

mattdowle le 7 déc. 2018

Confirmé fixe. Merci à @ltierney pour son aide.

Pour être complet au cas où nous aurions besoin de renvoyer ...
Je n'ai pas pu reproduire le problème avec R-devel compilé comme suit. (J'avais besoin de confirmer que je pouvais reproduire le problème avec 1.11.8 avant de pouvoir confirmer que 1.11.9 le 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"

même avec le script fourni par Luke:

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()

Au bout du compte, j'ai recompilé R-devel plus simplement comme suit, toujours avec --enable-strict-barrier ce qui est l'important:
./configure --without-recommended-packages --enable-strict-barrier
constellation réinstallée et toutes ses dépendances et data.table 1.11.8, et cette fois le script de Luke échoue correctement:

Fatal error: Wrong thread calling 'RunFinalizers'

L'installation de data.table-dev (1.11.9) dans ce R-devel et la réexécution, fonctionne bien. La réinstallation de data.table 1.11.8 échoue à nouveau. Donc, il est en effet fixé par 1.11.9. Dans ma compilation R-devel originale, peut-être que quelque chose faisait fonctionner 1.11.8 (désactivation du compilateur d'octets, -00, ASAN, etc.). Quoi qu'il en soit, une compilation R-devel plus simple était nécessaire et valait la peine d'être essayée.

@jangorecki Si le temps le permet, ce serait bien d'ajouter --enable-strict-barrier au R-devel utilisé dans les pipelines CI. Je ne sais pas si vous compilez R-devel ou non pour les pipelines CI.

mattdowle le 10 déc. 2018

@mattdowle oui je compile R-devel quotidiennement, j'y ajouterai ce drapeau. Ajouté pour ne pas oublier dans # 3147