Files
hammer/tools/portal-probe
sergioandClaude Opus 5 a5c959b618 🎯 portal-probe: omitir persist_mode MATA al portal — por eso Start no contestaba nunca
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>
2026-08-06 13:05:34 -04:00
..