Hola equipo de soporte de Posit,
Les escribo para reportar un error de compilación reproducible en el entorno de build de shinyapps.io, en la cuenta sernageomin-uhg.
RESUMEN DEL PROBLEMA
Al desplegar una Shiny app que depende de 'ggiraph', el build falla de forma consistente con un segmentation fault durante la instalación del paquete (no es un error de nuestro código; ocurre durante la fase de lazy-loading del propio paquete 'ggiraph', antes de que nuestro app.R se ejecute).
EL CRASH
El segfault ocurre dentro de la siguiente cadena de llamadas, que forma parte del código interno de 'ggiraph' (ejecutado automáticamente al compilar/instalar el paquete vía tools:::makeLazyLoading):
default_fontname() -> font_family_exists() -> gdtools::sys_fonts() -> systemfonts::system_fonts() -> subsetting de un tibble (db_sys[, nam]) -> vectbl_restore() -> * caught segfault , address ..., cause 'memory not mapped'
Traceback completo:
1: vectbl_restore(xo, x)
2: `[.tbl_df`(db_sys, , nam)
3: db_sys[, nam]
4: sys_fonts()
5: FUN(X[[i]], ...)
6: lapply(def_fonts, font_family_exists)
7: unlist(lapply(def_fonts, font_family_exists))
8: default_fontname()
9-10: eval(exprs[i], envir)
11: sys.source(codeFile, env, ...)
...
17: loadNamespace(package = package, ...)
20: code2LazyLoadDB(package, ...)
21: tools:::makeLazyLoading("ggiraph", "/usr/lib/R/00LOCK-ggiraph/00new", ...)
Resultado: "An irrecoverable exception occurred. R is aborting now ... Segmentation fault (core dumped)" y el build termina con:
Error: Unhandled Exception: child_task= child_task_status=failed: Error building image: Error building ggiraph (). Build exited with non-zero status: 1
ENTORNO DEL SERVIDOR (según el log de build)
- R 4.6.1 (/opt/R/4.6.1)
- Ubuntu 22.04 (jammy)
- Compilador: g++ (Ubuntu 11.4.0-1ubuntu1~22.04.3) 11.4.0, usando -std=gnu++20
- vctrs 0.7.3, tibble 3.2.1, systemfonts 1.3.2 (instalados como binarios justo antes del crash)
LO QUE YA PROBAMOS (todo sin éxito, mismo crash exacto en cada caso)
- ggiraph 0.9.6 + gdtools 0.5.1 (versiones más recientes de CRAN al momento del primer intento).
- Downgrade a ggiraph 0.9.2 + gdtools 0.4.4 (versión anterior, sin la lógica nueva de auto-detección de fuentes) -> mismo segfault, mismo traceback.
- Desplegar sobre un content id completamente nuevo (creamos 'uh_app_v2', content id 18011232, además del original 'uh_app', content id 18005438) -> mismo segfault en ambos, descartando que fuera un problema de caché/estado corrupto de un content id específico.
- Downgrade de rsconnect local de 1.11.1 a 1.11.0 (para igualar el entorno de otro despliegue nuestro que sí funciona) -> mismo resultado.
- Agregar 'showtext'/'sysfonts' como dependencias declaradas (por si cambiaba la resolución de versiones transitivas) -> mismo resultado, y además rompe el renderizado de símbolos Unicode localmente, así que lo revertimos.
DATO CLAVE: OTRA APP NUESTRA SÍ FUNCIONA
Tenemos otra Shiny app en la misma cuenta, 'calidapp' (content id 17726271), que usa prácticamente el mismo stack de paquetes (ggiraph, sf, gdtools indirectamente, etc.) y que SÍ se desplegó sin problemas al redeployarla el 25 de septiembre de 2026. Notamos que, a diferencia de los builds fallidos de 'uh_app', el log de build de 'calidapp' no mostró ninguna línea de compilación detallada de 'ggiraph' (los 'g++ ... .cpp' que sí aparecen en los builds fallidos): solo un resumen genérico de "Installing packages". Esto nos hace sospechar que 'calidapp' pudo haber reutilizado una capa de build/imagen ya compilada exitosamente en un despliegue anterior (la semana pasada), evitando así recompilar 'ggiraph' bajo las condiciones actuales del entorno, mientras que cualquier build nuevo de 'ggiraph' desde cero falla de forma consistente en este momento.
NUESTRA HIPÓTESIS
Algo cambió recientemente en el pipeline de build de shinyapps.io (posiblemente relacionado con la migración a R 4.6.1, que según las NEWS de R 4.6.1 cambió el estándar de C++ por defecto a C++20 en las plataformas donde está disponible) que está causando que la combinación actual de 'vctrs'/'tibble'/'systemfonts' (binarios) tenga un bug de compatibilidad que provoca este segfault al invocar systemfonts::system_fonts() y luego subsetear el tibble resultante.
LO QUE NECESITAMOS
¿Podrían revisar el pipeline de build para paquetes que dependen de 'systemfonts'/'gdtools'/'ggiraph' bajo R 4.6.1? Nos gustaría saber si:
(a) Es un problema conocido y ya identificado internamente,
(b) Hay alguna forma de forzar que nuestro despliegue reutilice una capa/build ya funcional (como parece estar pasando con 'calidapp'), o
(c) Hay un workaround de configuración de nuestro lado que no hemos identificado.
Quedamos atentos. Con gusto compartimos los logs completos de build si son de utilidad (los tenemos guardados de varios intentos).
Cuenta: sernageomin-uhg
Apps afectadas: uh_app (id 18005438), uh_app_v2 (id 18011232)
App de referencia que sí funciona: calidapp (id 17726271)
Saludos