Seen once while building the Linux present-owner probe (PR #1716) on the stacked #1699 branches (stage-B engine PR #1715). Not reproduced in eight later attempts, including the same sequence and idle gap.
Sequence: worktree displayxr-service (sim_display only, SIM_DISPLAY_FAKE_TRACKING=1) → weave_probe_vk_linux --dmabuf --no-release-wait (the negative control: the client reads the output without waiting the release fence) → client exits → ~90 s idle → a new PRESENT_OWNER client connects → service segfaults in libc on a client thread. The log ends right after the new client's extension dump (ext_weave_enabled: true), no backtrace. Side effect: the stale $XDG_RUNTIME_DIR/displayxr_comp_ipc socket makes the next service start fail with "Address already in use".
Log: ~/.cache/present-tmp/service_crash1.log on the Linux dev box (588 lines).
Suspects (unverified): teardown of the previous client's weave state in comp_multi_weave_linux.c (import-cache slots, deferred release fd, the wait-N-1 fence) racing the new client's bring-up; or the fd-less #else/refusal paths after a client that never waited the release fence. Worth a run of the same sequence under valgrind/ASan with the Linux engine on, and a check that comp_multi_weave_fini waits the in-flight fence before destroying slots.
Seen once while building the Linux present-owner probe (PR #1716) on the stacked #1699 branches (stage-B engine PR #1715). Not reproduced in eight later attempts, including the same sequence and idle gap.
Sequence: worktree
displayxr-service(sim_display only,SIM_DISPLAY_FAKE_TRACKING=1) →weave_probe_vk_linux --dmabuf --no-release-wait(the negative control: the client reads the output without waiting the release fence) → client exits → ~90 s idle → a newPRESENT_OWNERclient connects → service segfaults in libc on a client thread. The log ends right after the new client's extension dump (ext_weave_enabled: true), no backtrace. Side effect: the stale$XDG_RUNTIME_DIR/displayxr_comp_ipcsocket makes the next service start fail with "Address already in use".Log:
~/.cache/present-tmp/service_crash1.logon the Linux dev box (588 lines).Suspects (unverified): teardown of the previous client's weave state in
comp_multi_weave_linux.c(import-cache slots, deferred release fd, the wait-N-1 fence) racing the new client's bring-up; or the fd-less#else/refusal paths after a client that never waited the release fence. Worth a run of the same sequence undervalgrind/ASan with the Linux engine on, and a check thatcomp_multi_weave_finiwaits the in-flight fence before destroying slots.