[Bug]: Linux/X11 SIGSEGV in x11::Connection::GetRequestForFuture, followed by child SIGBUS #25625

Before submitting

• I searched existing issues and did not find a report of this symbolized fault.
• I included evidence to investigate it. I do not yet have a deterministic reproducer.

Area

apps/desktop

Summary

T3 Code intermittently exits on a Linux/X11 cloud desktop, losing the local backend and remote connection. One retained kernel record identifies a native SIGSEGV in x11::Connection::GetRequestForFuture(x11::FutureImpl*). Other T3 processes subsequently receive SIGBUS.

The invalid pointer and adjacent field value are consistent with a freed FutureImpl being used again, but that is a hypothesis, not a confirmed allocation/free history. This report does not establish that every observed exit has the same cause.

Related: #14259 describes a similar child-SIGBUS aftermath, but this incident includes an actual native general-protection fault, rather than only a silent exit.

Steps to reproduce

1. Run the Linux AppImage on an X11 cloud desktop.
2. Use T3 normally with agent sessions and remote access.
3. Intermittently, the desktop/backend becomes unavailable and requires relaunching.

No particular window action, preview operation, update check, or suspend/resume has been established as the trigger. The host does undergo VM pause/resume, but the faults are not all immediately adjacent to a recorded VM-fork event. I have not reproduced the crash in an isolated harness.

Expected behavior

The desktop and backend remain available during normal use. A native failure should leave enough diagnostic evidence to identify its origin.

Actual behavior and impact

Repeated desktop/backend interruptions. The local server disappears and remote clients lose access. Relaunching restores service; local database checks still pass.

Impact: major degradation or frequent failure.

Version and environment

• Linux x86_64 cloud desktop, Debian userspace, kernel 6.12.94+, X11.
• AppImage running via FUSE, normally launched with --no-sandbox --disable-dev-shm-usage --password-store=gnome-libsecret.
• Retained T3 package: 0.1.3-nightly.20261026.3717; current package: 0.1.3-nightly.20261026.3726.
• Retained runtime reports Electron 44.9.3, Chromium 152.0.7977.167.
• The fault's opcode sequence matches both retained/current Electron binaries. The exact crashed process's build ID was not captured before it exited, so the version attribution is based on matching retained binaries, not a core dump.
• The current Electron binary's GNU Build ID is 7db47e5a35567fc719591be4a7261ddf8ab64703.

Logs and symbolization

Raw kernel timestamps are used below. Converting historical dmesg timestamps to wall time is unreliable on this VM after pauses, so I am not forcing a timestamp/PID correlation with a particular desktop trace run.

[142398.018231] traps: t3code[1566537] general protection fault
  ip:55cbc0e4b577 sp:7ffedb3e8010 error:0
  in t3code[4d2d577,55cbbf54d000+9f2e000]
[142398.019970] t3code: t3code: potentially unexpected fatal signal 11.

RDI = 8074230400000000
RSI = 00000fbc0411e6e0
RCX = 00000000ffffffff

[142398.905135] t3code: t3code: potentially unexpected fatal signal 7.
  PID 1566766
[142398.927717] t3-resource-monitor: t3-resource-mon:
  potentially unexpected fatal signal 7.
[142445.145065] t3code: Chrome_ChildIOT:
  potentially unexpected fatal signal 7.

The first following SIGBUS is about 0.887 seconds after the general-protection fault. AppImage unmount fallout is plausible and resembles #14259, but there is no contemporaneous mount event in this capture to prove that chain.

Symbolization used the official electron-v44.9.3-linux-x64-symbols.zip:

• Archive SHA256: 652a6fb39a01582cb2f453dbf5265c38c9cc38cc0871afc178b92076a8300eda, matches the release asset digest.
• Breakpad module ID: 5A7EB47D5635C77F19591BE4A7261DDF0, corresponding to the retained ELF Build ID.
• The executable LOAD segment's virtual address is 0x1000 above its file offset. Kernel file offset 0x4d2d577 therefore maps to symbol address 0x4d2e577.

FUNC 4d2e570 77 0 x11::Connection::GetRequestForFuture(x11::FutureImpl*)
4d2e577 6 887 ... ../../ui/gfx/x/connection.cc

4d2e574: mov 0x8(%rsi),%ecx
4d2e577: sub 0x338(%rdi),%ecx  <-- fault

The source at line 887 is:

SequenceType offset = future->sequence() - first_request_id_;

The faulting read uses the noncanonical address 0x8074230400000338, before the following request-queue bounds check.

Interpretation, with limits

FutureImpl stores connection_ at offset 0 and sequence_ at offset 8. Chromium's pool-offset freelist encodes its next entry by reversing the bytes of a pool offset, with an inverted shadow word beside it.

Here:

• Reversing 0x8074230400000000 gives the aligned pool offset 0x04237480.
• The low 32 bits of its inverted shadow would be 0xffffffff, matching the value loaded from future + 8.

This is consistent with a freed request object's allocator metadata being interpreted as live fields. Without the full shadow word, slot state, stack, or allocation history, I cannot identify the freeing caller or exclude another corruption path.

Chromium issue 524824288 and its related GeometryCache reentrancy fixes were checked. The matching Chromium 152 sources already use Peek() in GeometryCache::GetBoundsPx(); I am not claiming this is that already-fixed issue.

No matching core/minidump was found locally. The current main process has a zero core limit, and Crashpad contains only its client ID. A bounded local capture is now attached to the current main thread to record registers, stack and small object-memory excerpts if another fatal signal occurs. It has not captured a new fault yet. No credentials, full traces or process-memory dumps are attached to this public report.

Workaround

Relaunching restores availability, but does not prevent another crash.

A standalone server with web/mobile clients would avoid this desktop Electron/X11 path; migration of this particular environment has not been tested. Merely extracting the AppImage or switching to a .deb still uses Electron/X11 and is not a demonstrated fix for this fault.

Could you advise whether this fault signature matches a known Electron/Chromium lifetime issue, and what additional capture would be most useful before pursuing a runtime change?