Causa raíz de que ScreenCast se quedara colgado en Start, medida en metal (OptiPlex 3060).
No era el EGL por software de QEMU: en metal, con iris por hardware, pasaba exactamente
lo mismo. Esa hipótesis queda falsificada.
Lo que pasa de verdad, con cuatro segfaults reproducibles (uno por intento, todos `at 0`
y todos en el MISMO offset de libc, 0x34f64 = `strlen`):
1. el cliente no manda `persist_mode` ⇒ el portal asume PERSIST_MODE_NONE
2. el backend de COSMIC devuelve `restore_data` de todos modos
3. xdg-desktop-portal 1.18.4 entra por la rama NONE de
xdp_session_persistence_generate_and_save_restore_token, que hace
`g_clear_pointer(in_out_restore_token, g_free)` — token = NULL
4. a la vuelta, el llamador hace `g_variant_new_string(*in_out_restore_token)` SIN
comprobar nada ⇒ glib llama strlen(NULL) ⇒ SIGSEGV
El portal muere JUSTO ANTES de emitir el Response. Desde el cliente eso se ve como «Start
aceptado y nunca contesta», que es indistinguible de un backend que se cuelga — y nos
mandó a buscar el problema en la GPU durante meses.
Con persist_mode >= 1 el token se genera (uuid) y no hay nulo. Es un fallo de aguas
arriba; esto lo esquiva desde el cliente sin tocar el portal. Por defecto 1 (transitorio),
que es lo que quiere cualquiera que sólo va a capturar una vez.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Redirigida a fichero, stdout se bufferiza por bloques: mientras la sonda espera un
Response el log muestra sólo la línea de la llamada. Eso se lee como «se colgó al
llamar» cuando en realidad estaba esperando como debe. Nos pasó depurando ScreenCast en
metal — dos minutos mirando un fichero que no avanzaba, con la sonda perfectamente viva.
setvbuf(_IOLBF) incondicional, no sólo cuando la salida es una terminal: el caso que
importa es justamente el redirigido.
Una sonda que no se puede leer MIENTRAS mide es media sonda.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`Start` de ScreenCast y el `Screenshot` interactivo ABREN UN SELECTOR: no terminan hasta
que alguien elige una pantalla. Tenían 60s clavados, y en metal eso alcanza para que la
sonda se rinda antes de que nadie llegue a hacer clic. El informe entonces dice «el
portal aceptó la llamada y no contestó», que se lee como un fallo del portal cuando la
cadena está simplemente esperando.
Es el mismo error de método que ya nos costó tres diagnósticos falsos en esta campaña
(initramfs 5s, cosmic-diag 50s, wifi-up 6s): medir contra el reloj en vez de contra el
hecho. Acá el hecho depende de un humano, así que el reloj tiene que ser AJUSTABLE, no
adivinado.
Los plazos de CreateSession/SelectSources siguen en 15s a propósito: esos pasos no le
piden nada a nadie, y si tardan es que algo anda mal de verdad.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bug que la propia sonda destapó al usarla: los portales son servicios ACTIVABLES por
D-Bus, no demonios siempre presentes — el bus los arranca cuando alguien los pide,
leyendo su `.service`. `NameHasOwner` NO dispara esa activación, sólo pregunta.
Costó una corrida entera de diagnóstico: la sonda dijo "nadie posee
org.freedesktop.portal.Desktop — no hay frontend de portal en el bus" sobre un
sistema donde el portal andaba perfecto, sólo que dormido.
Ahora pide `StartServiceByName` y deja que el bus decida. Si de verdad falta el
`.service`, falla con ServiceUnknown y ahí el diagnóstico sí es real; y distingue
"arrancado ahora" de "ya estaba corriendo", que no es lo mismo cuando lo que se
investiga es una carrera de arranque.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los portales NO son RPC: son un protocolo asíncrono en dos tiempos. Cada método
devuelve al instante un object path de `Request`, y el resultado llega DESPUÉS como
señal `Response` sobre ese path. `dbus-send` ya salió para entonces — por eso la URI
del FileChooser nunca se pudo capturar desde el shell.
Y hay una razón más dura: el portal ata la sesión al SENDER. CreateSession con un
dbus-send y SelectSources con otro llegan de nombres únicos distintos y el segundo se
rechaza. Hace falta UNA conexión viva durante todo el intercambio.
El path del Request se PREDICE (/…/request/<sender>/<token>, sender = nombre único
sin ':' y con '.'→'_'). Eso existe a propósito: permite suscribirse ANTES de llamar.
Esperar al path devuelto para recién ahí hacer AddMatch es una carrera real — el
portal puede haber emitido ya la señal.
En C y no con ashpd: el árbol fuente de esta receta es el repo de la propia
herramienta de build, así que ashpd significaría sumar ~150 crates al Cargo.lock de
hammer por una sonda de diagnóstico. libdbus ya está en la imagen y en el corpus
(y con `libdbus-1.a`, así que la sonda sale ESTÁTICA, sin un solo NEEDED). Sobre
todo: acá el protocolo se VE. Una sonda cuyo valor es documentar un handshake no
debería esconderlo tras una biblioteca que lo abstrae.
Cuatro modos: `version` (qué interfaces sirve y en qué versión), `screencast` (el
handshake de 4 pasos hasta el fd de pipewire), `filechooser` (captura las uris) y
`screenshot`. El impresor de valores es recursivo y NO filtra: si el portal devuelve
un campo que este programa no conoce, sale igual por pantalla — que es exactamente lo
que uno quiere de una sonda.
Validado en el host contra el portal real: compila sin warnings y lee las versiones
(Screenshot v2, FileChooser v4, Settings v2).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5